Looking at buying an existent Crypto Publication Needs to have atleast 500k + monthly views and a good enough amount of years sharing news to the world DM's open submitted by /u/amu4biz [link] [Kommentare]
The Setlur et al result that scaling test time compute without verification or RL is provably suboptimal keeps showing up in my reading and I think it deserves more weight than the "yet another scaling paper" treatment it got. The core claim is that verifier based methods, RL or search guided by a verifier, dominate verifier free methods like distilling successful traces, given a fixed compute budget, and the gap widens as the test time budget grows. What I find underappreciated is how cleanly this maps onto what the deployed systems are now converging on. The single agent ReAct loop is the verifier free extreme, you sample a trace and keep it, maybe with some self reflection that is still the same model grading itself. The multi agent setups that actually move numbers split the verifier off into a separate process. Apodex is the most explicit example I have seen, they train the team behavior in and run a verification team, conflict reviewer, fact checker, draft reviewer, that does not share the reasoning trace, and the reported lift is coming from the verifier not from added parameters. Same trained model, heavy duty mode adds double digits on BrowseComp and FrontierScience-Research. That is exactly the regime the theory predicts, the verifier is where the gain lives. The reason I think this matters beyond benchmark watching is that it reframes where the next chunk of capability comes from. If you believe the VB over VF result, then the path is not just bigger models or longer traces, it is better verifiers that are structurally independent of the generator. The pseudo correctness framing fits here too. The failure mode the verifier has to catch is not the obvious hallucination, it is the answer that passes every self check but is still wrong, and that failure mode is invisible to any verifier that shares context with the generator. What I want to hear from others is the open questions. My list. How much of the verifier gain is transferable to domains without clean reward signals, since the math proof case is the easy one. Whether the independence has to be architectural, separate agents, or whether a sufficiently disciplined prompt separation on one model gets you most of the way. And whether the VB advantage keeps widening or saturates once the verifier itself becomes the bottleneck. The practical version of this for anyone building. If your agent loop has the same model reviewing its own work, you are in the VF regime and the theory says you are leaving capability on the table. The cheapest structural change is to make the verifier a different process with denied context, even if it is the same weights. submitted by /u/Mysterious_Sign_9501 [link] [Kommentare]
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?
Attached is a screenshot of my top holdings and returns. I believe in bitcoin and ether the most. Should I let go of my alts or continue to hold open to suggestions. submitted by /u/thegoodlife1980 [link] [Kommentare]
Update to my original post A few weeks ago I made a post because my ETH withdrawal got stuck in “Initiating” without a TXID and remained there for weeks. At first I believed it was just a temporary technical issue and that support would eventually solve it, but after weeks of getting nowhere I decided to investigate the exchange myself. For weeks I was trying to understand why my withdrawal wasn’t moving. Support kept asking for patience, tickets received generic responses and Telegram admins eventually stopped replying altogether. The only way to get their attention again was to create a new Telegram account and ask questions publicly inside the official group. Every time I did that, admins suddenly became active again while private messages continued to be ignored. A few days ago I reached the point where I simply couldn’t accept that my funds might be gone, so I started spending time on blockchain explorers trying to understand what was actually happening. During the last two days I began analyzing AscendEX hot wallets across multiple chains: Arbitrum Ethereum BSC Polygon Solana Arkham Multichain hot wallet: 0x983873529f95132BD1812A3B52c98Fb271d2f679 What I found was very concerning. The exchange appears to hold millions of dollars in assets, but most of the value comes from newly listed low-liquidity project tokens such as REUR, ASD, FTRB and other small-cap tokens. AscendEX constantly lists new projects and users deposit USDT, ETH and other liquid assets to buy them, but when users want to withdraw their funds, certain assets and networks appear to become extremely difficult to withdraw. While my ETH withdrawal remained stuck, some of their wallets contained almost no native ETH. At the same time trading activity continued normally and markets remained active. Personally, after monitoring the exchange activity and wallet movements during the last several days, I became convinced that a significant part of the exchange volume is likely generated by market-making bots. Markets remain active, orders continue moving and volume looks healthy even while users struggle to withdraw certain assets. During my research I also discovered another Telegram group (t .me / ascendexx) Inside that group I recognized several usernames that I had previously seen asking questions inside the official AscendEX Telegram group before being banned. I was eventually banned myself after repeatedly asking questions regarding my withdrawal. Speaking with these users confirmed many of my suspicions and showed me that my case was not an isolated incident. The most important thing I learned is that support was completely useless. The only progress I made came from monitoring the wallets myself. I started checking which assets were actually available on specific chains and whether enough liquidity existed before attempting withdrawals. After identifying a token that was present in one of their wallets, I performed a small test withdrawal and it succeeded. At this point I have managed to recover a small portion of my funds and I continue withdrawing through assets that still appear to have available liquidity and that can easily be exchanged elsewhere after withdrawal. The fact that users have to monitor exchange wallets in real time in order to determine which assets can actually be withdrawn should concern everyone using this exchange. Everything I learned came from blockchain analysis, wallet monitoring and communication with other affected users. Support never explained which assets were working, which networks had problems or how users could recover their funds. At this point I strongly do not recommend depositing funds to AscendEX under any circumstances. In my experience, getting money into the exchange is very easy, but getting it back out can become extremely difficult. If you currently have funds on AscendEX, I would strongly recommend testing small withdrawals immediately and verifying that the assets you hold can actually be withdrawn before depositing anything else. submitted by /u/itsckomi [link] [Kommentare]
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.