This article delves into author Sam Jordison's reflections on his controversial "Crap Towns" book series.
Published around the turn of the millennium, the book humorously ranked UK towns based on public nominations and the author's observations, aiming for affectionate satire. Looking back, Jordison grapples with whether such a book could be published today, noting a perceived shift in cultural climate and the joke feeling less appropriate amidst increased inequality and hardship. The comments section echoes these concerns, discussing changing social dynamics, economic stratification, and the impact of social media on humor.
Author's Reflection on "Crap Towns"
Sam Jordison reflects on his experience writing the "Crap Towns" book series, which humorously ranked UK towns. He describes the original intent as affectionate satire, designed to spark conversation about regeneration and national identity while poking fun at poor planning and local quirks.
Why Not Today?
A central question Jordison addresses is whether a book like "Crap Towns" could be published in the current cultural climate. Many journalists believe it couldn't. Jordison wonders if this reflects a loss of British self-deprecation or if the humor simply hasn't aged well. He finds modern online equivalents "grubby" and cruel.
He points to factors like "identitarian politics," "puritanical outrage," and the "policing of humour" making publishers hesitant. While generally against silencing humor, he acknowledges that the UK's state hasn't improved since the book's release – facing austerity, Brexit, and increased hardship – which makes the joke feel less like lighthearted teasing and more like "punching down." Ultimately, he feels the world has moved on, and the joke no longer feels right, stating he wouldn't write another such book now.
Community Discussion
The comments section features a rich discussion largely agreeing with the author's points and expanding on them.
Changing Context for Humor
Many commenters concur that the context for this type of humor has fundamentally changed. The author suggests increased "atomisation" and "hardening of inequalities" make shared jokes harder, questioning the modern focus on whether humor "punches up" or "punches down." Users feel the UK has become genuinely "crap" for many, making the joke too painful.
Impact of Social Media
The rise of social media is highlighted as a key factor. Unlike in 2003, the targets of the jokes can now instantly respond and voice displeasure, drastically altering the dynamic. Humor, commenters argue, is deeply tied to context, and the current context of deep economic and social inequality transforms what might have been collective self-mockery into perceived bullying.
Economic and Social Factors
Extensive commentary focuses on underlying economic and social shifts. Users discuss the radical divergence in towns' fates – some gentrifying, others declining – making a blanket "crap towns" label cruel. Increasing geographical wealth stratification, particularly between London/South East and other regions, is seen as a major driver. Commenters debate inequality's role, citing austerity cuts' tangible impact on local services in poorer areas and the housing crisis as sources of hardship. This economic malaise and perceived abandonment by elites are seen by some as fueling populism and making mockery of struggling places unacceptable.
The "Political Correctness" Debate
The "political correctness" aspect also sparks debate. Some argue complaints about "PC" simply mean old jokes don't land because sensibilities have changed. Others argue it's active suppression or "mob rule" preventing certain humor, citing instances of cancellation or police involvement over jokes.
Nature of the Joke and Media Landscape
Finally, there's reflection on the joke itself. Some question if the original book was ever truly "affectionate," noting the author's discomfort with modern online equivalents. The challenges for independent online creators are also mentioned, noting how larger outlets freeboot content, dominating search results and making it hard for original sources to gain traction – another way the digital world has changed.
Explore the Berkeley Humanoid Lite, an initiative aiming to democratize humanoid robotics.
Berkeley researchers have introduced the Humanoid Lite, an open-source, accessible, and customizable humanoid robot platform. Designed to combat the high cost and closed nature of current robotics, it utilizes 3D printing and off-the-shelf components. The project aims to lower barriers for research and development in the field.
Democratizing Humanoid Robotics
The Berkeley Humanoid Lite project aims to make humanoid robotics research and development more accessible. The core motivation is to address the high cost, proprietary nature, and lack of transparency prevalent in the field, which currently hinder progress.
Design and Cost
A key aspect of the Berkeley Humanoid Lite is its focus on accessibility through design. It features a modular body and actuator gearbox design that is entirely 3D-printed. All components are sourced from widely available e-commerce platforms, keeping the total hardware cost under $5,000 based on US market prices. The team specifically chose a cycloidal gear design, found optimal for 3D-printed parts, to mitigate the strength limitations of plastic compared to metal. Extensive testing was conducted to validate the durability of these 3D-printed actuators.
Performance and Open Source
To demonstrate capabilities, the team developed a locomotion controller using reinforcement learning, successfully achieving zero-shot policy transfer from simulation to the physical robot. By making the hardware design, embedded code, and training frameworks fully open-source, they hope to democratize the field. They propose a "performance factor per dollar" metric to compare cost-effectiveness, claiming a high factor at a low price point.
Community Feedback
The Hacker News comments section shows a mix of enthusiasm and critical discussion regarding the project.
Enthusiasm for Open Source
Many commenters appreciate the open-source nature and the goal of democratization. They see it as a positive step, suggesting that solving hardware problems allows focus to shift to challenging software aspects and lowers barriers for researchers and hobbyists. The idea of open-source robotics being part of the future resonates strongly.
Cost and Manufacturing Debate
The cost and manufacturing approach sparked debate. While aiming for accessibility via 3D printing and off-the-shelf parts, some question if $5,000 is truly "Lite" or low-cost for a 3D-printed robot. A counterpoint is that a $5,000 open-source option pressures pricing of mass-produced, closed-source competitors. There's also discussion on whether 3D printing is the most cost-effective method for mechanical parts compared to mass production, though others argue it's excellent for low-volume R&D where rapid iteration is crucial.
Performance Metric Criticism
The "performance factor" metric introduced in the paper drew significant criticism, particularly from engineers. Commenters found the metric potentially misleading or overly simplistic, arguing that combining torque, degrees of freedom, and size into a single factor doesn't accurately capture robotic complexity and accessibility. Some noted the full Berkeley Humanoid appears significantly more performant by this metric, questioning the trade-offs for the "Lite" version.
Getting Started in Robotics
A related discussion emerged around getting started in hobby robotics, with users asking for guidance. This led to suggestions ranging from simpler projects to more advanced platforms like HuggingFace's LeRobot and ROS2, highlighting the diverse entry points and tools available.
Future Applications
Finally, comments touched on future applications of humanoid robots, particularly in the home. The consensus is that general-purpose robot butlers are still very difficult, and it might be easier to reconfigure environments for robots than make robots flexible enough for complex home tasks like taking out trash or folding laundry.
Dive into the frustrating world of ./configure scripts and a proposed solution for their single-threaded slowness.
Traditional ./configure scripts, often generated by tools like Autoconf, are notoriously slow and sequential. They perform numerous independent checks on the build environment one after another, failing to utilize modern multi-core processors. A new proposal suggests leveraging make -j to parallelize these checks, dramatically speeding up the configuration phase and improving CPU utilization.
The Problem with ./configure
The ./configure script is a ubiquitous part of building software, especially in the Unix/Linux world. Its primary function is to check the build environment for necessary features, such as the presence of headers, functions, or specific compiler capabilities.
Why It's Slow
These checks are typically performed by compiling and linking small test programs. The fundamental issue, as highlighted by Tavian Barnes, is that ./configure scripts are inherently sequential. They execute one test after the next, even though most tests are independent of each other. This is an "embarrassingly parallel" problem, yet major build systems like Autoconf, CMake, and Meson do not parallelize this configuration step, leading to significant delays, often longer than the actual compilation phase on modern multi-core machines.
The Proposed Solution
Tavian Barnes proposes an elegant solution to parallelize the configuration process.
Leveraging make -j
Instead of a single shell script running tests sequentially, the approach involves creating a configuration makefile (configure.mk). This makefile defines targets for each individual check. Each check compiles a small test file and outputs its result to a temporary file. Since each check is a separate make target, make -j can run many of them concurrently. The main Makefile and config.h are then generated by concatenating the results of these parallel checks. A simple ./configure shell script wraps this process, invoking make -j with an appropriate job count.
Results
The result, demonstrated with the author's bfs project, is a dramatic speedup and much higher CPU utilization during configuration. The configure step becomes significantly faster than the subsequent parallel build, effectively eliminating a common bottleneck.
Community Discussion
The comments section on Hacker News reveals widespread developer frustration with build systems and explores various perspectives.
Autotools Pain Points
Many commenters echoed the sentiment that Autotools is complex and often painful, describing it as a "mess." They noted that scripts are frequently copied blindly, leading to unnecessary checks for features long present in standard libraries, contributing to bloat and slowness.
Comparisons to Other Systems
The discussion branched into comparisons with other build systems. CMake was frequently mentioned as a more popular and "saner" alternative, though some found it still problematic and noted it also doesn't parallelize configuration. Meson was brought up as a strong alternative, often preferred over CMake. Rust's Cargo was mentioned for its dependency handling but noted as Rust-specific.
Alternative Approaches
Several alternative configuration approaches were discussed:
- Using plain Makefiles or simple hand-written scripts for simple projects.
- Leveraging modern compiler features (
__has_attribute,__has_include) to reduce the need for some tests, though limitations were noted. - Folding configuration checks into the main build process using tools like Ninja.
- Caching configure results (
configure -C) for repeated runs, though reliability concerns were raised. - Having system files provide environment info instead of running tests (less popular due to portability concerns).
Why Configure Speed Matters
Commenters highlighted various reasons developers run ./configure multiple times, making its speed important, including changing branches, updating dependencies, bisecting bugs, bootstrapping systems, and building for multiple environments. For tasks like rebuilding a distribution, the cumulative configure time across hundreds of packages is a significant bottleneck.
Broader Parallelization
A tangent debated why the dream of automatic parallelization from functional programming hasn't fully materialized, citing overhead, data dependencies (Amdahl's Law), compiler limitations, and complexity of shared memory/GC.
Overall, the discussion reinforced frustration with traditional build systems' configuration speed and complexity, while acknowledging the difficulty of the problem. Tavian's proposal was seen as a clever, practical way to apply existing tools (make) to parallelize a historically sequential process.
Discover a fascinating browser demo showcasing realistic cloth physics using Verlet integration.
A recent Hacker News post highlighted an interactive web demo by @cloudofoz demonstrating realistic cloth physics. The simulation uses the Verlet integration method, commonly employed for particle systems like cloth or ropes. Users can interact with the fabric in the browser, observing its stretching, folding, and reaction to gravity, showcasing the power of physics simulations in a web environment.
Interactive Cloth Physics
The article centers on a web-based demo that allows users to interact with a simulated piece of cloth.
The Verlet Demo
The demo showcases realistic fabric behavior using the Verlet integration method. This technique is popular in physics simulations for its stability, particularly for systems of connected particles. The interactive nature allows users to drag points on the cloth, change its type (to a grid), and observe how it responds to simulated gravity and user input, providing a compelling visual experience of soft-body physics.
Community Reactions
The Hacker News comments section shows significant appreciation for the demo and delves into technical and historical aspects of physics simulations.
Appreciation and History
Many commenters found the demo "cool," "lovely," and "impressive," highlighting the mesmerizing quality of realistic physics. Users shared links to other browser-based cloth simulations, including older ones dating back over a decade, and discussed the history of cloth physics in video games (e.g., Splinter Cell, Hitman, Mirror's Edge), noting that while not entirely new, a smooth, interactive browser version is still compelling.
Technical Deep Dive
Technically, comments explored the Verlet integration method itself, discussing its advantages (stability, energy preservation) and disadvantages compared to other numerical integration techniques like Euler or Runge-Kutta. The "instability" or "bouncing" seen in some simulations was attributed to the nature of discrete approximations and error accumulation. Verlet's popularity in game development was linked to papers detailing its implementation, suggesting it became a go-to method due to its simplicity and stability relative to basic Euler, though damping is often needed.
Skill Gap in Physics Simulation
Another prominent theme was the perceived skill gap between typical web/enterprise development and building physics simulations. Commenters from web backgrounds expressed wonder or frustration at the transition from "component integration" to computationally intensive physics and numerical analysis. Experienced developers emphasized the need to learn fundamental math, physics, and numerical methods from scratch, noting that simulations are "content-heavy" and constrained by single-process performance, unlike the "structure-heavy" and distributed nature of much web development. Some shared personal anecdotes about learning physics intuitively by coding simple simulations early on.
Other Notes
Lighter comments included playful suggestions for interaction (like using phone breath) and discussions about the feasibility of robots folding clothes (noting the difficulty of manipulating deformable objects despite simulation advances). The potential application of better cloth simulation in robotics was also mentioned.
Uncover the surprising ability of OpenAI's o3 model to guess photo locations with remarkable accuracy.
Simon Willison's post highlights the impressive geolocation capabilities of OpenAI's o3 large language model. By analyzing visual cues within a photograph, the model can accurately guess the location where it was taken, often down to the town level, even without metadata. This capability, achieved through a detailed, simulated analytical process, is both entertaining and raises significant privacy concerns.
AI Geolocation Capabilities
The core theme is the unexpected and advanced ability of OpenAI's o3 model to determine the geographical location of a photograph based solely on its visual content.
How o3 Analyzes Photos
The process is simple: upload a photo to ChatGPT (using o3 or o4-mini) and ask for the location. The model demonstrates a detailed, multi-step "thinking" process. It analyzes visual clues like architecture, vegetation (specific plants), weather patterns, and attempts to read fine details like license plates. A striking feature is its simulated "zooming" and use of Python code to crop and analyze specific image areas repeatedly over several minutes, mimicking a forensic investigation.
Impressive Accuracy
The results are notably accurate. In the author's test with a photo from El Granada, California, the model correctly identified it as Central Coast California and named the specific town as its second guess. This accuracy holds even when EXIF data is stripped, relying purely on visual analysis and its vast training data correlating visual cues with locations. Successful tests were also conducted with photos from Madagascar and Argentina.
Comparison to Other Models
The article compares o3's performance to other models like Claude and Gemini. While others can also guess locations, o3's integrated tool usage and simulated "zooming" process are presented as particularly advanced and unique, highlighting the power of integrating tools directly into the model's chain-of-thought.
Implications
The technology has significant implications, both positive and negative.
Entertainment vs. Dystopia
On one hand, the capability is described as "wildly entertaining," akin to living in a CSI episode, showcasing the fun and impressive aspects of modern AI. On the other hand, it is deemed "deeply dystopian" due to major privacy implications. The ease with which a seemingly innocuous photo can be used to pinpoint someone's location is a critical concern, underscoring the need for public awareness about this technology's capabilities. An update notes that while o3 might have some rough user location context, the photo analysis works independently.
Explore a compelling theory linking prostate problems to faulty venous valves and a potential mechanical solution.
An article from yarchive.net discusses a theory by doctors Gat and Goren proposing that common prostate issues like BPH and cancer stem from faulty valves in spermatic veins. This failure causes testosterone-rich blood to backflow into the prostate, stimulating excessive growth. A minimally invasive procedure to block these veins is suggested as a potential treatment, a concept now being pursued by a startup.
The Prostate Problem
The article addresses the prevalence and deadliness of prostate problems in men, specifically benign prostate hyperplasia (BPH) and prostate cancer. It notes the surprising frequency of these issues given the prostate's size and metabolic activity compared to other organs. Traditional explanations like STIs are discussed but found insufficient.
The Gat/Goren Theory
The core of the article explores a theory by Israeli doctors Gat and Goren.
Faulty Valves and Testosterone
Their hypothesis suggests BPH, prostate cancer, and male infertility (varicocele) originate from faulty one-way valves in the spermatic veins. When these valves fail, blood flows backward due to gravity when standing. This backflowing blood, rich in free testosterone from the testicles, spills into the prostate via connecting veins. This high concentration of free testosterone bathing prostate cells is theorized to cause excessive growth.
The Proposed Procedure
Gat and Goren proposed sclerosing (blocking) the faulty spermatic veins using a catheter. The idea is that other veins take over drainage without the problematic backflow into the prostate.
Analyzing the Theory and Evidence
The author analyzes the Gat/Goren theory from a mechanical perspective and examines supporting evidence.
Hydrodynamics vs. Hydrostatics
While acknowledging spermatic vein backflow when valves fail, the author critiques Gat and Goren's simple hydrostatic pressure explanation, suggesting a more complex hydrodynamic mechanism involving pulsating flow is needed to explain why backflow reaches the prostate.
Evidence for "Sneaky T"
A recent paper by Alyamani et al. found significantly higher testosterone levels in prostatic veins compared to peripheral blood, supporting the idea of direct testicular blood flow to the prostate ("sneaky T").
Clinical Results and Limitations
Gat and Goren reported promising clinical results treating BPH and early prostate cancer with their sclerosing procedure. Limitations include potential recurrence due to new venous bypasses and difficulty experimentally proving backflow into the prostate itself. Simple, cheap screening using thermal imaging is suggested.
Why Slow Adoption?
The article discusses reasons for slow adoption of such a potentially impactful theory and treatment, including lack of patentable drugs, medical conservatism, fear of malpractice, insurance hurdles, and the perception of it being "just plumbing."
Community Engagement
The comments section shows significant engagement with the article's ideas.
Startup Validation
A major point of discussion is validation from a commenter who attended a presentation by Vivifi Medical, a startup actively developing a procedure based on this principle. The Vivifi CEO joined the thread, confirming they are building on Gat and Goren's work with a refined "snipping" and "splicing" method they believe is superior and prevents recurrence. They are conducting clinical trials and aim for FDA approval around 2028, reporting encouraging early BPH reversal data.
Mechanical Theory and Medicine 3.0
Many commenters resonated with the emphasis on the mechanical nature of the theory, contrasting it with statistics-driven medicine. They expressed a desire for more personalized, diagnostic-led medicine ("medicine 3.0"), though acknowledging the difficulty of observing internal mechanisms.
Simple Screening
The suggested simple screening method using thermal imaging sparked discussion about underutilized low-cost diagnostic tools versus the medical system's tendency towards expensive technology.
Evolutionary Blind Spots
The article's point about evolutionary blind spots for late-onset diseases was popular. Commenters discussed how selective pressure drops off after reproductive age, allowing conditions like BPH to persist, and debated whether grandparenting provides enough advantage to select against them.
Lifestyle and Alternative Theories
Several commenters brought up lifestyle factors and alternative theories, including the importance of healthy muscle motion (pelvic floor, diaphragm, walking) for venous return, potentially linking to the mechanical theory. Dietary factors and the potential link between chronic prostatitis symptoms and musculoskeletal issues were also noted.
Challenges of Innovation
The challenges of medical innovation adoption were echoed, highlighting hurdles of funding, regulation, insurance, and physician inertia.
Existing Treatments
Existing medical treatments for BPH (5-alpha-reductase inhibitors, Tadalafil) were mentioned, with discussion on their effectiveness, side effects, and whether medication constitutes a "cure" versus a procedure.
Examine the case of an Australian man who ordered radioactive materials online, sparking a major incident and debate over official overreach.
An article from Chemistry World details the case of Emmanuel Lidden, who ordered small samples of radioactive materials like uranium and plutonium online for a collection. This triggered a large hazmat response and legal charges. Despite pleading guilty, he received a good behaviour bond without conviction, as the judge found no malicious intent. The incident sparked debate, with many arguing the official reaction was excessive given the minimal risk posed by the quantities involved.
The Incident
The article focuses on the events surrounding an Australian man's online order of radioactive materials.
Ordering Radioactive Samples
Emmanuel Lidden, 24, ordered various radioactive samples, including uranium and plutonium, over the internet with the stated goal of collecting the entire periodic table.
The Hazmat Response
The delivery of these materials to his parents' apartment in Sydney in August 2023 triggered a significant hazmat incident. This involved Australian Border Force, firefighters, police, and paramedics, leading to street closures and home evacuations due to perceived danger.
Legal Outcome
Lidden pleaded guilty to two charges under the 1987 nuclear non-proliferation act: importing and possessing nuclear material without a permit. Despite the guilty plea and the disruption, the judge sentenced him to a two-year good behaviour bond without recording a conviction, concluding he had mental health issues but no malicious intent. His solicitor criticized the Border Force's handling as a "massive over-reaction," stating the quantities were harmless and that scientists found the case "ridiculous." Lidden reportedly made no attempt to hide his identity or the materials.
Community Reaction
The Hacker News comments section largely echoed the sentiment that the authorities' reaction was excessive and the case absurd.
Official Overreach and Absurdity
Many commenters pointed out that numerous everyday items contain small amounts of radioactive substances (smoke detectors, uranium glass, bananas), arguing the minuscule quantities Lidden imported posed virtually no danger unless intentionally misused. The case was widely seen as an absurd overreaction by authorities.
Criticism of Authorities
A strong theme was criticism of the authorities' handling. Users highlighted reports suggesting Border Force knew the materials were harmless but allowed delivery before staging the dramatic response, seen by some as deliberate theater to strengthen the prosecution's case. Commenters expressed frustration with perceived implicit lying and abuse of power. The authorities' mention of mercury (also ordered) being used in "dirty bombs" was ridiculed as ignorant fear-mongering.
"Mental Health Issues" Debate
The judge's finding of "mental health issues" sparked debate. Some saw it as a legal justification for leniency, while others viewed it as a potentially damaging label or "fig leaf" unfairly stigmatizing the defendant despite the lack of conviction. Discussion included whether this incident would appear in background checks and impact future employment.
Broader Topics
The conversation touched on broader topics like the transparency of criminal justice systems, contrasting public naming practices in the Anglosphere with more private approaches elsewhere. Brief tangents included the relative risks of nuclear waste vs. fossil fuel emissions and the use of depleted uranium in munitions.
Overall, the prevailing sentiment was that the case was a gross overreach by authorities driven by fear and ignorance about radiation, disproportionately punishing a hobbyist for actions posing minimal actual risk.
Discover RetrOS-32, a self-written hobby operating system running on vintage IBM ThinkPads.
Hacker News user joexbayer shared their passion project, RetrOS-32, a 32-bit x86 operating system built from scratch. Featuring graphics, multitasking, and networking capabilities, the OS runs on vintage hardware like IBM ThinkPads and various emulators. A key component is a self-written 32-bit C compiler, embodying the project's philosophy of writing everything oneself to avoid porting existing software.
Introducing RetrOS-32
RetrOS-32 is a hobby operating system developed by joexbayer.
Key Features and Philosophy
It is a 32-bit x86 operating system primarily written in C and Assembly for the kernel and utilities, with C++ used for userspace applications. Notable features include graphics support, multitasking, and networking capabilities. A significant achievement is the inclusion of a self-written 32-bit C-Compiler specifically for the i386 architecture. The project adheres to a strict "write everything yourself" philosophy, aiming to build components from the ground up rather than porting existing software.
Hardware Support and Roadmap
RetrOS-32 is designed to run on older hardware, including various IBM ThinkPads, Asus Eee PCs, and Dell Optiplex models. It can also be tested in emulators like QEMU or the v86 web emulator. The project has an extensive roadmap outlining future features such as a custom bootloader, various drivers (PCI, ATA IDE, WiFi), a network stack (TCP, HTTP, SSH), a graphical window manager, a custom VM for bytecode, and various applications.
Community Appreciation and Discussion
The comment section shows significant appreciation and enthusiasm for the RetrOS-32 project.
Enthusiasm for Hobby OS Dev
Many users congratulated the author on the impressive achievement, particularly getting the OS to boot on real, vintage hardware, calling it a major milestone. This sentiment of valuing passion projects and low-level development was echoed by several commenters who shared their own experiences or aspirations in OS development.
Technical Feedback
Technical discussions included feedback and suggestions. The system's default font was a recurring topic, with suggestions for alternatives, though the author acknowledged the difficulty of font rendering and plans to address it. Questions about hardware compatibility included inquiries about porting to ARM platforms (like Raspberry Pi), which requires a full port due to architectural differences. Interest in future WiFi support was also expressed.
Custom Compiler Details
A user specifically asked about the custom C compiler, prompting the author to explain its function (compiling to i386 machine code using interrupts for syscalls), current limitations (basic types, no switch statements), and unique features (functions in structs).
Development Process
The author also shared insights into their development process, admitting to starting without a strict plan but adhering to the goal of writing everything from scratch, copying ideas rather than code. This approach has led to some technical debt but kept the project engaging. A suggestion for a UI refresh was acknowledged by the author as a personal weakness they might revisit.