HackerNews Digest

The OpenJDK commit 858d2e434dd replaces the original `ThreadMXBean.getCurrentThreadUserTime()` implementation, which read `/proc/self/task//stat`, parsed a complex string with `sscanf`, and converted clock ticks to nanoseconds, with a direct `clock_gettime()` call. The old method required multiple syscalls (open, read, close), VFS processing, kernel‑side string formatting, and user‑space parsing, causing a 30‑400× slowdown versus the simpler `getCurrentThreadCpuTime()` that already used `clock_gettime(CLOCK_THREAD_CPUTIME_ID)`. The new code obtains a thread‑specific `clockid_t` via `pthread_getcpuclockid()`, flips the low bits to request VIRT (user‑time‑only) clocks, and calls the existing `os::Linux::thread_cpu_time()` wrapper. Benchmarks on a Ryzen 9950X show average latency dropping from ~11 µs to 0.28 µs (≈40×) and further micro‑benchmarking reduces it to ~70 ns, a 13 % gain by constructing the clockid manually (PID = 0) to use the kernel fast‑path that skips the radix‑tree lookup. The change, a 40‑line edit, landed Dec 3 2025 and will be part of JDK 26 (Mar 2026), delivering a substantial performance improvement for `ThreadMXBean.getCurrentThreadUserTime()`.

GitHub objects have two identifier schemes. The older format encodes a string of the form “:” and is base‑64‑encoded (e.g., `MDEwOlJlcG9zaXRvcnkyMzI1Mjk4` → `010:Repository2325298`). Newer objects use a global node ID prefixed by an object type (e.g., `PRRC_kwDOL4aMSs6Tkzl8`). The suffix is a base‑64‑encoded MessagePack array: `[version, repository‑DB‑ID, object‑DB‑ID]`. Decoding yields the repository ID and the object’s database ID; the object ID is always the last array element. Because the MessagePack payload is 96 bits, the lower 32 bits correspond to the database ID, allowing extraction via a simple bitmask (`decoded & 0xffffffff`). Legacy IDs persist for older repositories and certain object types (e.g., Users), while newer repositories receive the MessagePack‑based IDs. The first array element appears to be a version marker. Converting a node ID to its database ID can be done with: ```python import base64, msgpack def node_id_to_db_id(node_id): _, enc = node_id.split('_') return msgpack.unpackb(base64.b64decode(enc))[-1] ```

vLLM 0.11.0 completes migration to the V1 engine, enabling higher‑throughput inference for large MoE models such as DeepSeek‑V3. Community benchmarks on a CoreWeave H200 cluster (Infiniband ConnectX‑7) report sustained 2.2 k tokens / s per GPU—up from ~1.5 k tokens / s—thanks to kernel upgrades (SiLU‑mul‑quant fusion, Cutlass QKV kernels, TP‑attention fixes) and Dual‑Batch Overlap (DBO) for decode. Key techniques: - **Wide‑EP**: combines expert parallelism with data parallelism, sharing a single expert set across ranks and avoiding tensor‑parallel duplication of latent‑attention projections, improving KV‑cache utilization. - **Dual‑Batch Overlap (DBO)**: overlaps micro‑batch compute with all‑reduce communication, reducing idle GPU time. - **Expert Parallel Load Balancing (EPLB)**: hierarchical/global policies rebalance token routing dynamically to prevent rank idling. - **Disaggregated serving**: separates prefill and decode phases, mitigating delay from compute‑bound prefill requests in EP groups. Supported deployment stacks include llm‑d (Kubernetes), Dynamo (high‑throughput/low‑latency), and Ray Serve LLM (modular Ray‑based serving). Ongoing roadmap items cover elastic EP, long‑context serving, KV‑cache CPU transfer, full determinism, and large‑MoE kernel fusions.

The author, co‑hosting a San Francisco event on 16 Jan 2026, reflects on the J.P. Morgan Healthcare Conference (JPM HC) held 12‑16 Jan 2026 at the Westin St. Francis. They note that, despite extensive online presence—official website, press articles, AI‑generated LinkedIn posts—no one they know has physically attended the conference, and media coverage lacks personal anecdotes, focusing on generic phrases (“pipeline updates,” “cautiously optimistic”). Drawing a parallel to the 1835 Great Moon Hoax, the author suggests the conference’s reality is indistinguishable from a well‑executed hoax. They invoke Thomas Schelling’s “focal point” concept, proposing JPM HC functions as an industry‑wide coordination device rather than a conventional meeting. Extending this, the author speculates that the Westin hotel sits above a massive subterranean organism that requires drug infusion, positioning the biotech sector as a caretaker for this entity and explaining California’s economic centrality. The piece frames the conference as a ritualistic, almost religious gathering, while acknowledging the speculative nature of these theories.

None

The page is titled “ASCII Clouds” and provides a short list of available visual presets for the application. Two preset names are shown: **DefaultTerminalRetro** and **CRTCosmicFogRed**. No additional description, usage instructions, or technical details are included beyond these identifiers. The content consists solely of the title and the two preset options, indicating a selection interface for different ASCII‑based cloud rendering styles. No further information about functionality, configuration parameters, or implementation is present.

The puzzle considers a fair coin flipped, observed by Alice who lies 20 % of the time. Trusting Alice alone yields an 80 % correct guess. Adding Bob, who also lies independently 20 % of the time, does not improve accuracy: the optimal strategy—guess the most likely outcome for each reported pattern—still gives 80 % success. A detailed probability table shows four cases (both truthful, both lying, one truthful/one lying) each contributing 64 %, 4 %, and two 16 % scenarios where a random guess yields 50 % correctness, summing to 80 %. Simulations of one‑million trials confirm the result. Introducing a third independent liar (Charlie) raises accuracy to 90 % because a majority vote breaks ties; a fourth (David) restores an even number of voters and the gain disappears. This mirrors Condorcet’s Jury Theorem: with independent voters each correct with probability > ½, the majority decision’s correctness approaches 100 % as the odd voter count grows, while even counts add no information without a tie‑breaker.

Cannot provide a summary because the supplied input contains only a title and no substantive content to summarize.

Sei is an AI platform for financial services backed by Y Combinator and other investors. The company seeks a senior DevOps/Platform/AI Infrastructure Engineer to help scale its product for enterprise customers. The stack includes a TypeScript backend, React frontend, Python AI agents, and AWS‑based infrastructure managed with Terraform and Kubernetes. Key responsibilities are auto‑scaling services, cost optimization, operating open‑source monitoring and security tools, and managing WebRTC servers, PSTN gateways, and STT/TTS/LLM deployments. Candidates must have strong AWS, Kubernetes, and Terraform experience, exposure to AI/ML and large language models, and a track record of building systems from zero to production. The role emphasizes continuous 360° feedback, product ownership, rapid execution, and a humane, collaborative culture. Work is location‑based in Gurgaon or Chennai (minimum four days per week) with an intense, high‑accountability environment. Compensation includes a competitive salary, equity, and flexibility in cash‑equity split.

Japan’s large construction firms invested heavily from the late 1970s in robotics to address high labor costs and stagnant productivity. Initial single‑task robots (e.g., SSR‑1 fire‑proofing sprayer, 1983) evolved into integrated “building factories” that moved the factory onto the jobsite. Core technologies included rail‑mounted gantries, vertical lifts, climbing platforms, and just‑in‑time delivery of prefabricated steel, concrete floor slabs, and façade panels; single‑task robots performed welding, cutting, and finishing. Notable systems were Shimizu’s SMART, Akatuki‑21 (with ground and sky factories), Obayashi’s ABCS/Big Canopy, T‑Up, AMURAD, and others. Reported outcomes (1990s‑early 2000s) showed 20‑70 % labor reductions per task, 15‑30 % construction‑time savings on high‑rise projects, up to 70 % waste reduction, and improved site weather protection. Drawbacks were long (≈1‑3 months) and costly factory set‑up, limited applicability to tall buildings, extensive design coordination, and long pay‑back periods (e.g., AMURAD ≈ 8 buildings, ~20 years). By the 2010s the systems were no longer in commercial use, though Shimizu continues R&D on newer site‑wide robotic platforms.