'There's a rot at the core of Tinseltown...'
Eastern Washington had cheap power and tons of space. Then the suitcases of cash started arriving.
Could humans ever hack alien technology using an Apple laptop? Thankfully, this movie answers the question.
The new lazy comment’s “AI-generated”.
Exploring the internal representations of Pangram 3.3.2
Deep, AI-written investment thesis on 500+ leading US stocks, grounded in filings, earnings, and the numbers.
Worrying about whether AI can do your job is a blind alley, Cory Doctorow argues. The real danger is AI’s bubble: a speculative fantasy built on convincing bosses to replace workers with systems that can’t actually do what their salesmen promise.
On the 67th edition of the TOP500, LineShine debuts as the new No. 1 system, ending El Capitan's run atop the list and becoming the fifth Exascale system overall. It is the first China-based system to lead the TOP500 since Sunway TaihuLight in 2017. LineShine is installed at the National Supercomputing Centre in Shenzhen (NSCS), China, and was built by the Shenzhen Cloud Computing Center. It submitted a debut measurement of 2.198 Exaflop/s on the HPL benchmark, more than 20% ahead of the No. 2 system, using 13,789,440 cores. The system is based on the custom "LingKun" platform with 304-core LX2 processors running at 1.55 GHz, the proprietary LingQi interconnect, and Kylin OS. LineShine also takes over the No. 1 spot on the HPCG ranking with 22.00 Petaflop/s. On the HPL-MxP benchmark, which measures mixed-precision performance, LineShine debuts in fourth at 7.92 Exaflop/s with a more modest 3.6x speedup, consistent with its CPU-only design. El Capitan, Frontier, Aurora, and JUPITER Booster all remain Exascale-class systems and now occupy No. 2 through No. 5, all still installed at the same sites as last edition. The El Capitan system at the Lawrence Livermore National Laboratory, California, USA, moves to No. 2 on the TOP500. The HPE Cray EX255a system holds at 1.809 Exaflop/s on the HPL benchmark. LLNL's 17.41 Petaflop/s on HPCG now places the system No. 2 on that ranking as well, behind LineShine. El Capitan has 11,340,000 cores and is based on AMD 4th generation EPYC processors with 24 cores at 1.8 GHz and AMD Instinct MI300A accelerators. It uses the Cray Slingshot 11 network for data transfer and achieves an energy efficiency of 60.94 Gigaflops/watt. The Frontier system at the Oak Ridge National Laboratory, Tennessee, USA, is the No. 3 system on the TOP500, holding at an HPL score of 1.353 Exaflop/s. Frontier is based on the HPE Cray EX235a architecture and is equipped with AMD 3rd generation EPYC 64C 2GHz processors. The system has 9,066,176 total cores and also relies on Cray's Slingshot 11 network for data transfer. The Aurora system at the Argonne Leadership Computing Facility, Illinois, USA, holds the No. 4 spot on the TOP500 with 1.012 Exaflop/s on the HPL. Aurora is built by Intel based on the HPE Cray EX - Intel Exascale Compute Blade, which uses Intel Xeon CPU Max Series processors and Intel Data Center GPU Max Series accelerators communicating through Cray's Slingshot-11 interconnect. The JUPITER Booster system at the EuroHPC / Jülich Supercomputing Centre in Germany moves to No. 5, still measured at exactly 1.000 Exaflop/s and remaining the first European Exascale system. JUPITER - JU Pioneer for Innovative and Transformative Exascale Research is located at the Forschungszentrum Jülich campus in Germany and is operated by the Jülich Supercomputing Centre. It is based on Eviden's BullSequana XH3000 direct liquid-cooled architecture, utilizing Grace Hopper Superchips. Rmax and Rpeak values are in PFlop/s. For more details about other fields, check the TOP500 description. Rpeak values are calculated using the advertised clock rate of the CPU. For the efficiency of the systems you should take into account the Turbo CPU clock rate where it applies.
Moody Mush: an Interactive Mushroom Robot: Pat it, poke it, or let it glow softly on your desk. Moody Mush responds with changing moods expressed through light, sound, and motion. It’s an interactive mushroom robot designed to be beginner‑friendly while still aiming for an expressive and cut…
LLMs have broken legibility of effort - our ability to tell, at a glance, whether something took a human real work. What happens next?
I'm a software engineer in San Francisco, currently working on a platform to streamline release management for VPCs: Bottlerocket. Posts 2026-06-23 A Rust macros use case: Tightly-coupled API definitions for the client and server A Rust macros use case: Tightly-coupled API definitions for the client and server I’m working on a Kubernetes operator and an API server for it to interface with. Both of these are crates in the same Rust workspace. The motivation for this was that I wanted to define all of the types used by the two services in one place, and keep the services tightly-coupled. When writing the operator, I wrote a protocol to define the HTTP requests the operator sends to the server: pub trait ApiPath { type Request: serde::Serialize; type Response: serde::de::DeserializeOwned; const METHOD: Method; const PATH: &'static str; } So that I could define paths/endpoints like this: pub async fn send(&self, body: P::Request) -> Result { let url = format!("https://{}/{}", self.host, P::PATH); self.client .request(P::METHOD, url) .bearer_auth(&self.token) .json(&body) .send() .await? .error_for_status()? .json::() .await } This worked super well when implementing the operator. All I had to do was call this generic send function with a struct that implemented ApiPath, which reduced a lot of boilerplate code, and let me define the method, body type, response type and path all in one place for each endpoint. When I started implementing the API server, which I used the axum crate for, I was having a hard time adding the routing/handling in an elegant way using the protocol I created for the operator. When defining a route in axum, you usually do something like this: axum::Router::new().route("/poll", axum::routing::get(poll)); The issue here though is that I’m now defining the path and method for each endpoint in a different place. I could do something like this, but I don’t really like how I’m specifying the endpoint struct in two places: axum::Router::new().route(Poll::PATH, method_to_handler_func(Poll::METHOD)(handler)); I was only vaguely familiar with macros and thought I’d see if this would be a good use case. After some iteration I got this: macro_rules! into_route { ($path:ty, $handler:expr) => { axum::Router::new().route(::PATH, from_method(::METHOD, $handler)) }; } * from_method just matches the http::Method to the axum handler, e.g. axum::routing::get. Now I can just define my router like this: let operator_routes = axum::Router::new() .merge(into_route!(Poll, poll)) .merge(into_route!(ListImages, list_images)) All I have to do is pass in the struct implementing the ApiPath protocol and the handler function! This was my first practical use of macros, and I thought it was interesting enough to share.
Abstraction boundaries pay off
hit record, voice what's on your mind, and put it out there.