“I just chose words carefully”
The post discusses challenges of typesetting in monospace fonts. Regular left‑aligned text works, but right‑aligning requires manual space counting, centering is imprecise because half‑spaces do not exist, and full justification creates uneven large gaps. Hyphenation, common in proportional fonts, appears conspicuous in monospaced text and disrupts copy‑paste. Consequently, full justification is rare in plain‑text files. The author cites rs1n’s 1990s “Super Metroid” guide as an exception: every line was manually crafted to reach the right margin without double spaces, resulting in 17 000 words of perfectly aligned text produced solely with an ASCII editor. The FAQ confirms no special program was used—only careful word selection. The post notes that similar manual adjustments occur in book layout to avoid widows/orphans and in UI strings to fit constrained widths.
P99 0 ms* autocomplete for 240M domain names
The article details an autocomplete system for Wirewiki, covering ~240 million domain names with p99 latency effectively at 0 ms (results ready before key‑up). The client prefetches suggestions on keyDown for the typed character plus the next possible character, then renders on keyUp. Latency budget is derived from two key‑press durations plus inter‑key gap; empirical testing gave a p99 of 121 ms for typical typing speed. The API uses a two‑tier index: a head trie (in‑memory) storing the top‑8 suggestions for every prefix from the Tranco top‑1 M domains (O(length) lookup), and a tail SSD‑backed, memory‑mapped block index of the remaining CZDS domains (≈2.5 GB, 240 M entries) searched via binary‑search of a 27 MB directory followed by linear scan of a 256‑name block (O(length·log N)). End‑to‑end tests show most API calls complete in ≈2 ms; at 1.6 k req/s, Nginx + API respond within 15 ms for 99 % of requests. Network latency (browser → Cloudflare → server) dominates, adding ≈10 ms, keeping total latency within the 121 ms budget for users near the European server, though distant users (e.g., USA) exceed it. Scaling via geo‑distributed servers could achieve true p99 0 ms latency.
The comments criticize the current autocomplete’s reliance on key‑up events, noting it adds noticeable latency, especially in regions like Australia, and results in suggestions for nonexistent domains, making the feature less reliable. Contributors suggest using key‑down triggers, optimizing the prediction model with weighted popularity, and caching trie nodes via a CDN to achieve near‑instant responses. Mobile usability concerns, handling of pasted or voice‑input text, and visual highlighting of matches are also raised. Despite these issues, the tool’s overall concept is regarded as clever and potentially useful.
Creepy Crawlies
Git.kernel.org is being overwhelmed by AI‑training crawlers that retrieve every commit as rendered HTML rather than cloning the repositories directly. The site handles ~6 million daily requests; ~66 % are blocked by a proof‑of‑work challenge (Anubis), while ~33 % solve it and reach the main service. Only ~2 % of traffic appears to be legitimate human activity. Rendering commits for scrapers consumes 14‑16 of the 90 CPU cores across five geo‑distributed nodes—about 20 % of total capacity—and the load fluctuates in spikes. Initial defenses (user‑agent filtering, IP/ASN bans) failed as bots switched to distributed residential and mobile IPs. The Anubis challenge raised computational cost for bots but they eventually adapted, prompting higher difficulty levels that also affect real users. Additional strain comes from poorly designed CI pipelines performing simultaneous shallow clones. The operators are now limiting crawlable URLs and gating expensive actions, while still offering full data downloads behind additional safeguards.
The comments express widespread frustration with the growing volume of automated scrapers that overload sites, especially git‑hosting interfaces, and view proof‑of‑work schemes like Anubis as an ineffective arms race that harms legitimate mobile users. Contributors report custom mitigations such as native‑code accelerators, client‑side rendering, selective blocking, rate limiting, and authentication, while also proposing alternative approaches like micropayments, shifting computation to clients, or offering data via torrents. Overall, there is consensus that current defenses are costly, incomplete, and risk degrading user experience, prompting calls for more sustainable, economically balanced solutions.
Highlighting My Code Based on How Much I Care
The author reflects on Nikita Prokopov’s claim that functional syntax‑highlighting should use a minimal set of memorable colors. Using VS Code’s default dark theme, the author finds the palette too numerous to recall specific token colors (e.g., class names). Attempts to create a light theme reveal that achieving sufficient contrast on a white background forces darker, less vibrant hues, which can make elements stand out excessively.
To question the necessity of colored highlighting, the author experiments with a purely black‑on‑white layout, discovering that without any visual distinction code becomes “flat” and requires line‑by‑line reading. Re‑introducing contrast via grayscale tones yields a hierarchy:
- Comments – highest visual priority, as they convey intent and context.
- Variable and function definitions – highlighted to locate declarations quickly.
- Control‑flow terminators (
return,throw,yield) – marked for structural navigation.
Less important tokens (keywords like let, const, and punctuation) are muted or near‑invisible. Dynamic, click‑based highlighting for same‑word and scope/bracket navigation complements the static scheme. The overall goal is a highlighting system that emphasizes semantic elements while de‑emphasizing syntactic noise, enabling rapid scanning and focused reading.
Comments express a split view on syntax highlighting. Many criticize vibrant, rainbow‑style themes as distracting, especially for focus‑related concerns, and favor muted or grayscale palettes, structural cues, or minimal color sets. Others argue that selective coloring of language constructs speeds navigation and reading, and suggest enhancements like nesting‑based hues, underlines, or hover‑activated highlights. Some question the relevance of the issue or note readability problems with the article itself. Overall, the discussion centers on balancing visual clarity with minimal visual noise.
My hobby of building miniatures and taking pretty pictures
The author describes constructing an extensive miniature café, building on earlier projects such as a tiny library and Asakura train. The build required precise woodwork, frequent re‑attachment of fragile pieces, and long periods of focused work. While assembling, the author watched video‑game streams and Warhammer 40k lore, having recently purchased Adepta Sororitas and Black Templar figures without intent to field an army. The post contrasts the café’s detailed construction with real‑world coffee experiences, noting variability in bean quality and praising a local shop that roasts its own beans using a secret recipe known only to the owner. The author speculates the miniature café might also hide its own secrets. Images accompanying the text illustrate the café’s interior, intricate details, furniture, and assorted food items, emphasizing the realism and craftsmanship of the model.
The comments collectively express strong appreciation for miniature kits and their visual appeal, noting the joy of detailed construction and photography. Many share personal connections to model‑building, recalling childhood experiences, family involvement, or artistic techniques such as gouache shading. Positive remarks also appear about coffee preferences, with several users favoring simple brew methods over espresso‑based drinks. Suggestions include using watercolor for shading, maintaining a clean environment to avoid dust, and providing scale references to highlight the models’ size. Overall, the tone is enthusiastic and supportive of the hobby.
A 12TB Steam "teraleak" spills more than a decade of lost PC gaming history
The recent “teraleak” exposed a 12‑TB archive of Steam data, containing unreleased builds, betas, and prototype assets from Valve and numerous third‑party publishers that were stored on Valve’s servers before 2013. Highlights include:
- Early versions of Valve titles such as Left 4 Dead 2, CS: GO, and a canceled Portal sequel (F‑Stop), plus fragments of Half‑Life 3‑related files.
- Pre‑release builds from external developers, including Spore, Dragon Age: Origin, Batman: Arkham Asylum, Sonic the Hedgehog 4, and Spec Ops: The Line.
- No recent (post‑2010) releases are present, but the leak represents a large, centralized security failure for PC game development history.
- Legal concerns arise because the archive holds substantial third‑party content, making its distribution and analysis risky.
- The event parallels the 2015 Nintendo “gigaleak,” promising new insights into historic development processes while underscoring the need for stronger protection of developer assets.
The comment highlights the discovery of an obscure Steam release of League of Legends, noting its brief availability and the difficulty of extracting its assets due to a missing encrypted depot key. It references the leak’s request for community caching and torrent seeding to reduce server load and preserve the data, while expressing concern about potential legal complications for the hosting platform. The overall tone is informational and pragmatic, focusing on technical hurdles, archival intentions, and the practical limitations of personal storage capacity.
Understanding ChatGPT Work
ChatGPT Work comprises two offerings: Work Cloud, accessed via chatgpt.com or the mobile apps, and Work Local, the desktop app formerly called Codex. Both are restricted to paid plans ($20 / month +).
Key differentiators from standard ChatGPT:
- Model selection – Users can choose GPT‑5.6 (Sol, Luna, Terra) or GPT‑5.5, each with Light‑to‑Ultra reasoning levels, mirroring API‑available models.
- Code execution with internet access – The cloud environment can install packages, clone GitHub repos, and freely access external sites, unlike ChatGPT’s sandboxed interpreter.
- Full headless Chrome – A browser tool launches a Chrome instance, fills forms, runs JavaScript, captures screenshots, and handles login/2FA without routing credentials through the model.
- Persistent shared filesystem – Each session gets a scratch folder under /workspace/scratch that persists across sessions and is visible to all concurrent Work sessions.
- ChatGPT Sites – Users can generate and deploy static or dynamic sites on Cloudflare Workers, with optional public sharing.
- Sub‑agents & Skills – Work supports parallel agents (Sol/Luna/Terra) and exposes ~44 “skills,” e.g., control‑browser, with detailed API docs.
- Scheduled automations – Prompts can be set to run on a recurring schedule, triggering updates or notifications.
Safety concerns remain regarding data exposure, prompt‑injection risks, and agent‑controlled communication.
Comments highlight strong enthusiasm for ChatGPT Work’s ability to automate complex computer tasks, integrate with tools like Gmail and Google Docs, and even build Android apps, while noting its slower speed without premium tiers. Users critique confusing naming, unclear distinctions between “Work” and “Chat,” and limited enterprise‑focused marketing compared with competitors such as Claude Cowork. Privacy and safety concerns surface around agents accessing private data, and suggestions call for clearer boundaries and better documentation. Overall sentiment mixes appreciation for the feature set with frustration over usability, positioning, and security clarity.
Matrox: Graphics for Professionals
Matrox was founded in 1976 in Dorval, Quebec, by Lorne Trottier and Branko Matić to provide CPU‑video interfacing solutions. Early products included the MTX‑1632 (512‑byte video RAM with 32×16 ASCII output) and the MTX‑256² (256×256 raster graphics), which gained profitability through magazine promotion and early orders. The company’s first S‑100 bus card, the ALT‑256² (256×256 raster with 65 KB refresh memory), appeared in 1978, followed by the ALT‑512 (512×256 or dual 256×256 displays). By 1978 Matrox claimed >10 000 installations, including NASA’s Viking ground displays, and expanded to Multibus, DEC PDP‑11, and later IBM PC/ISA adapters (e.g., PIP‑512, MIP‑512). Significant milestones include the 1986 US‑Army $72 M EIDS contract, the 1987 PG‑1281 (TMS34010 32‑bit graphics processor, 1280×1024 resolution), and the 1987 SM‑640 Geometry Engine (6000 shaded polygons/s).
From the early 1990s onward Matrox introduced MGA‑based cards (Millennium, Mystique, G200, G400, G450, G550) supporting up to 16 MB WRAM/SGRAM, dual‑monitor output, DirectX/OpenGL acceleration, and later PCIe (G550, Parhelia). The company shifted focus to multi‑display, video capture, and embedded graphics; its Imaging division was sold to Zebra Technologies in 2022. Recent products include the 2019 Luma series (Intel ARC A310/A380) for industrial and medical signage, supporting multiple 8K/5K displays with HDR and 75 W TDP. Matrox remains active in professional graphics, video, and machine‑vision markets.
Comments collectively recall Matrox cards as reliable, high‑quality 2D graphics solutions with stable analog output, strong driver support, and useful dual‑head or multi‑display capabilities that appealed to Linux and professional environments. Users also note specialized features such as sync‑on‑green and video‑capture cards that served niche markets like medical imaging and digital signage. In contrast, many acknowledge limited 3D performance, higher cost, and eventual displacement by competitors such as 3dfx and Nvidia for gaming. Overall sentiment is nostalgic and appreciative of Matrox’s durability and niche strengths, while recognizing its shortcomings in mainstream 3D acceleration.
Formalization of the Solution to the Hopf Problem
The repository plby/HopfProblem contains a formal proof, developed in the Lean theorem prover, of the classical result that the six‑dimensional sphere S⁶ admits a complex manifold structure compatible with its standard topology—thereby resolving the Hopf problem. The code defines the necessary differential‑geometric objects (smooth manifolds, almost‑complex structures, integrability conditions) and constructs the specific almost‑complex structure on S⁶ derived from the octonionic multiplication. It then verifies the Newlander‑Nirenberg theorem within Lean to show integrability, yielding a genuine complex structure. The development includes:
- Formalizations of smooth manifolds, tangent bundles, and complex charts.
- A Lean implementation of the octonion‑induced almost‑complex structure on S⁶.
- Proofs of required curvature and torsion properties.
- A mechanized proof of the Newlander‑Nirenberg integrability criterion.
- Documentation and tests illustrating how the complex structure respects the standard topology of S⁶.
The project demonstrates how advanced differential‑geometric results can be encoded and verified in a proof assistant.
uv: Deduplicate all files in the wheel cache
The pull request introduces a buffer‑reuse optimization for the wheel cache when content hashing is enabled. Instead of allocating a new 64 KiB buffer for each file copied and hashed during streaming extraction, a single buffer is reused across the entire wheel, keeping the per‑wheel buffer size at 64 KiB. Benchmarks on Linux with pinned wheels and content‑addressed caching show reduced installation times: AnyIO improves from 110 ms to 107 ms (‑2.6 %), SymPy from 845 ms to 775 ms (‑8.3 %), NumPy from 627 ms to 567 ms (‑9.5 %), PyTorch CPU from 6.50 s to 5.99 s (‑7.8 %), and a 14‑package environment (concurrency 4) from 6.95 s to 6.47 s (‑7.0 %). Measurements comprise 16 paired rounds for individual packages, 12 for the full environment, and a total of 672 installs, excluding warm‑up and cache‑priming runs. Cached installs and local‑wheel controls exhibited no consistent change.
The comments collectively treat meticulous text alignment as a niche yet respected practice, recalling personal histories of manual justification in code, documentation, and early computing environments. Contributors express admiration for the discipline and its aesthetic benefits, while also noting that rigid justification can hinder readability and make revisions cumbersome. There is a recurring theme that constraints spur creative word choice, and many draw parallels to modern AI‑driven watermarking and tooling. Overall, the discussion balances nostalgic appreciation with pragmatic critiques of the technique’s practicality.