Hacker News, Distilled

AI powered summaries for selected HN discussions.

Page 264 of 359

Public/protected/private is an unnecessary feature

Role of access modifiers

  • Many commenters frame public/protected/private as tools to:
    • Mark what is stable API vs internal implementation.
    • Reduce cognitive load when reading unfamiliar code.
    • Signal who “owns” breakage when internals change (author vs user).
    • Help compilers/JITs optimize (e.g., inlining, representation changes).

Arguments that private/protected are unnecessary or harmful

  • Anything “private” can often be bypassed:
    • Reflection, unsafe accessors, name-mangling tricks.
    • Forking the library and removing/modifying access keywords.
    • Preprocessor hacks or pointer tricks in C++.
  • This leads some to argue privacy is mostly social signaling and should be a non-binding annotation (like TypeScript types or @internal), or omitted entirely.
  • Strict enforcement can hurt downstream maintainers when vendors change visibility across versions, making upgrades painful.
  • In contexts where you control the whole stack (e.g., backend services in containers), forking to expose internals is often seen as acceptable.

Arguments in favor of access control

  • Library and framework authors rely on private/internal members to:
    • Freely refactor internals without worrying about external dependencies.
    • Prevent consumers from coupling to fragile details and accruing tech debt.
  • In many settings (OSes, runtimes, proprietary apps, system libraries), consumers can’t realistically fork the dependency, so access control matters more.
  • Even in non-OOP or inheritance-light code, marking internal functions/fields reduces convention-based ambiguity and naming games like _DO_NOT_USE or _UNSAFE.

Soft vs hard privacy mechanisms

  • Some prefer “soft” privacy:
    • Python underscores and name-mangling; conventions over enforcement.
    • Go’s package-private vs exported (capitalization-based) model.
    • C#/Java internal/assembly/package-level visibility; namespace-based “internal” APIs.
    • Common Lisp’s exported vs unexported symbols.
  • Others argue that once annotations for privacy are standardized, they effectively become language features, so they might as well be enforced.

Inheritance, composition, and OOP context

  • The original article’s stance is tied to a broader “inheritance is an antipattern” view; several commenters reject this.
  • Many see private/protected and inheritance as valuable for:
    • Partial implementations in base classes.
    • GUI frameworks and other extensible systems where subclassing is common.
  • Others push for composition, traits/protocols, and FP-style patterns instead, but concede that pure composition can become verbose and awkward.

Resurrecting a dead torrent tracker and finding 3M peers

Legality vs. Risk of Running / Reviving a Tracker

  • Many argue a bare tracker is “content‑neutral” and likely legal in some jurisdictions, especially if it honors takedowns and blacklists hashes.
  • Others stress that the real issue isn’t strict legality but lawsuit risk: cease‑and‑desist letters, DMCA notices, and expensive civil litigation can be ruinous even if you ultimately win (“the punishment is the process”).
  • Several see a strong chilling effect: fear of copyright lawsuits discourages technically legal experimentation.
  • There’s disagreement on how “aiding and abetting” applies:
    • One side notes that knowingly facilitating piracy via a well‑known piracy domain could be seen as intent.
    • Another side emphasizes high criminal burden of proof and the general legality of dual‑use infrastructure (like ISPs, search engines).

Trackers vs. Torrent Indexes and Intent

  • Distinction is made between:
    • Trackers: simple peer coordination by infohash.
    • “Trackers” as websites: indexes, metadata, search, communities.
  • Enforcement historically focused on the latter, where inducement and clear knowledge of infringement are easier to show.
  • Some argue reviving a known piracy tracker domain after observing legacy traffic signals intent; others counter that the tracker only sees hashes and IPs, not the underlying content.

Jurisdiction, Enforcement, and Honeypot Concerns

  • Copyright enforcement is said to be driven mainly by rights holders, not police, via DMCA and ISP complaints.
  • Examples are mentioned of US tracker shutdowns and the role of domain/TLD/VPS jurisdiction (US vs. Moldova vs. “run it in Russia/China/Iran”).
  • A few suggest an FBI or rights‑holder honeypot is an obvious use case; others note such tactics are already used via DHT and swarm monitoring.

Technical Behavior: Persistence, DHT, and Hijacking

  • Commenters are struck by how many clients still pinged a long‑dead tracker, analogous to stale NTP or 1.1.1.1 traffic.
  • DHT and multi‑tracker lists mean swarms usually survive even if one tracker dies; old torrents can still be found years later.
  • Reviving dead tracker domains could:
    • Enable large‑scale DDoS by pointing DNS at arbitrary IPs.
    • Redirect DMCA complaints to innocent residential IPs.
    • Be used to map or index torrents (similar to DHT crawlers).

Security and Exploit Potential

  • Multiple people wonder if malformed tracker responses could exploit buggy clients; some note prior remote‑code‑execution issues in clients.
  • Libtorrent and fuzzing are cited as partial reassurance, but older/unsafe clients are seen as plausible targets.

Broader Reflections on BitTorrent

  • Several lament that legal pressure wiped out small, high‑quality, niche trackers more than mass‑piracy sites.
  • Others note P2P never truly died (private trackers, seedboxes, file lockers, DHT), and praise BitTorrent as foundational tech that influenced later decentralized systems.

Brad Lander detained by masked federal agents inside immigration court

Role of Protests, Voting, and Political Pressure

  • Some argue people should call representatives, protest, and organize electorally, seeing mass demonstrations as both awareness-building and a path to midterm change (e.g., 2026 House races, weakening executive power via Congress).
  • Others are deeply pessimistic: they cite 2024 results, gerrymandering, voting-machine concerns, and prior huge protests (Iraq war, George Floyd, Roe v. Wade) that didn’t change core policies.
  • There’s a strong current that normal protests are insufficient; meaningful change may require sustained disruption, strikes, or civil disobedience, not just marches.
  • Fears that elections may be unfair or meaningless compete with the belief that “doomerism” is self-fulfilling and that voting is still the main lever.

ICE, Parallel Legal Systems, and Authoritarian Drift

  • Many see immigration enforcement as a parallel, more permissive legal system: lower burdens of proof, weaker rights, looser evidence rules, and “expedited removal” with minimal judicial oversight.
  • Masked, semi-anonymous ICE-style operations are described as “paramilitary” and “Nazi-like,” especially when they refuse to identify themselves or show warrants, creating conditions indistinguishable from kidnapping or cartel activity.
  • Some commenters note this trajectory began with DHS post‑9/11 and has expanded under both parties; others stress the current administration’s rhetoric, quotas, and links to Project 2025 as qualitatively worse.
  • Debate over sanctuary policies: one side calls local noncooperation a democratic choice reflecting community priorities; the other calls it defiance of national law that helped justify harsher federal crackdowns.

What Happened With Lander and the Legal/Moral Dispute

  • One camp says he obstructed a lawful federal arrest: he had no official role in that courtroom, no right to see documents, knew he was in a federal immigration court, and should expect detention if he physically interferes.
  • The opposing camp views his actions as a reasonable attempt to prevent an apparent extrajudicial seizure by masked agents who would not present a warrant or clearly identify themselves, especially in an environment of fake-cop assassinations.
  • There is disagreement over key facts: whether agents were in recognizable uniforms, whether they must show a warrant in that context, and what legal authority they had to detain a citizen.
  • Some see his brief detention and release as routine handling of obstruction; others see it as intimidation of a political figure and part of a broader pattern of targeting opposition strongholds.

Due Process, Noncitizens, and Abuses

  • Several commenters highlight deportations without meaningful hearings, mistaken detention of citizens, and transfers to foreign or offshore facilities, arguing that due process is effectively being stripped from many immigrants.
  • Others reply that expedited removal and warrantless immigration arrests have existed for decades; the law allows this for certain categories, and the new element is optics and targeting, not legal authority.
  • Trust in the system is seen as eroded by documented misidentifications, resistance to oversight, and quota‑like pressure (“3,000 per day”), making even lawful tools suspect in practice.

Libertarians, 2A Culture, and Selective Anti‑Authoritarianism

  • Longtime libertarian critiques of administrative and “specialty” courts are noted, but there’s sharp criticism that many right‑libertarians and gun‑rights advocates are silent or openly supportive when abuses target immigrants or “out‑groups.”
  • A recurring theme: rhetoric about resisting tyranny was largely conditional on who is targeted; many armed citizens are unlikely to resist when enforcement aligns with their politics.

Meta: Media Framing and HN’s Role

  • Multiple comments attack misleading or sensational headlines, including the initial Hacker News title, and stress sticking to the article’s wording.
  • Others broaden this into a critique of “narrative” news, hyperreality, and post‑truth dynamics, but still see this case as evidence of a real authoritarian shift worth discussing even on a tech‑focused site.

Tesla Robotaxi launch is a dangerous game of smoke and mirrors

Market bets and Tesla valuation

  • Multiple commenters report large Tesla put positions but also note they’ve lost money shorting in the past; Tesla is described as a “cult/meme stock” whose price often ignores fundamentals.
  • Some expect robotaxi reality to puncture the valuation; others argue the stock has repeatedly defied bad news and that timing a collapse is extremely risky.

Musk’s motives, ego, and politics

  • Debate over whether Musk is primarily mission-driven, profit-driven, or power/ego-driven.
  • Some see him as willing to burn money for ego (e.g., Twitter), others point to his fight for a huge compensation package as evidence he cares deeply about extracting wealth.
  • Several think his political behavior has badly damaged the Tesla brand; others doubt politics will matter if robotaxis work and are cheap.

Vision-only FSD vs lidar and geofencing

  • Widespread skepticism that vision-only can safely handle all conditions (weather, complex city streets) vs lidar-heavy, geofenced approaches like Waymo.
  • Concern that Musk has personally framed adopting lidar as defeat, and that retrofitting past “FSD-ready” cars could trigger massive liability.
  • A minority argue vision-only will eventually work with more data, and that keeping hardware cheap is key for mass deployment.

Safety, regulation, and liability

  • Many expect serious crashes; some predict a disaster worse than past Uber/Cruise incidents given low reported miles-per-critical-disengagement.
  • Strong calls for criminal accountability if FSD kills people, countered by arguments that car makers already cause fatalities within regulated frameworks.
  • Discussion of limited existing standards covering FSD and claims that Tesla sidesteps or flouts some reporting/terminology norms.
  • Robotaxis without drivers raise questions: who is liable for pedestrian deaths, and will political allies shield Tesla?

Real-world user experiences with FSD

  • Experiences diverge sharply:
    • Some say current FSD (especially on newer hardware) handles thousands of miles with rare interventions and is already safer or more pleasant than human driving in good conditions.
    • Others found it “dangerous” or unusable in dense urban areas or bad weather, requiring frequent takeovers and being clearly inferior to Waymo.
  • Several note it works best on freeways and in mild weather; snow and complex city environments remain problematic.

Waymo vs Tesla: data, tech, and progress

  • Commenters highlight that Waymo has fewer but richer miles (full sensor suites, detailed logs, large-scale simulation) versus Tesla’s huge but mostly low-signal camera data excerpts.
  • Argument that quality, diversity of “hard miles,” and strong simulators matter more than raw mileage counts; Tesla’s lack of lidar and weaker simulation are seen as structural disadvantages.
  • Waymo is credited with a substantial commercial lead (millions of paid rides, expanding geofenced areas), while Tesla has no true robotaxi service yet.

Robotaxi launch expectations and teleoperation

  • Many expect the “launch” to be extremely constrained: few cars, geofenced areas, remote operators, odd restrictions (times, routes), or further delays.
  • A late job posting for teleoperation engineers days before launch is seen as evidence the system isn’t ready and may be heavily “Mechanical Turk-ed.”
  • Some fear opaque small-scale rollouts will hide serious problems until a major incident occurs.

Media bias and perception

  • Some claim Electrek has become reflexively anti-Tesla; others point out its earlier pro-Tesla stance and argue that turning critical now is itself evidence of Tesla’s trajectory.
  • Broader discussion on online echo chambers (Reddit, HN) and how they distort perceptions of Musk, Tesla, and public sentiment.

Broader implications of robotaxis

  • Discussion of robotaxis competing with human gig drivers and with public transit, especially in car-centric US cities.
  • Concerns about vandalism and misuse of unattended vehicles, and that safety for bystanders (not riders) is the key social risk.

Making 2.5 Flash and 2.5 Pro GA, and introducing Gemini 2.5 Flash-Lite

Real‑world usage outside coding

  • Frequent non-coding uses: translation, long-document summarization, research reports, web/Youtube summarization, web scraping → semi-structured data, NDA/contract extraction, converting handwritten or scanned text to spreadsheets, real-estate listing feeds, home automation, math exploration, audio transcription, and “book club” / journaling / self‑reflection.
  • Vision and multimodal: praised for handling large batches of images cheaply and reliably (e.g., product Lexikon), YouTube access and giant context window were repeatedly cited as differentiators.
  • Many use Flash / Flash-Lite for “cheap and fast” tasks, often as a delegate from a larger model to generate or edit structured objects.

Model quality & comparisons

  • Several users say Gemini 2.5 Pro is strong for translation, summarization, law-like writing, math help, and long-context drafting; some prefer its writing tone and research depth to ChatGPT.
  • Others find Gemini worse than Claude or OpenAI for serious coding or complex reasoning, describing it as verbose, off-topic, or “Buzzfeed-style” in tone.
  • Some report very good coding performance and stable code from 2.5 Pro (especially via tools like Aider), but complain about excessive comments and try/except clutter.
  • There’s a sense that preview versions of 2.5 Pro felt smarter, more willing to push back, and less sycophantic than the GA release.

Long context & benchmarks

  • Users praise the 1M-token window for translation, big-doc Q&A, and “pile of NDAs”‑type workflows.
  • A detailed subthread debates long-context evals (NIAH, MRCR, RULER, LongProc, HELMET).
    • One side: Gemini 2.5 Pro collapses after ~32k tokens on internal enterprise benchmarks; long-context reasoning is still weak across all models.
    • Other side: in real-world doc‑assembly tasks (reports/proposals) 2.5 Pro performs uniquely well.
  • Consensus: long context is useful but far from “solved,” and benchmark choice strongly affects perceived performance.

Product tiers, UX, privacy

  • Gemini app, AI Studio, and Vertex behave differently:
    • Gemini app: smaller thinking budgets, stronger safety filters, nerfed behavior; often underperforms API/AI Studio.
    • AI Studio: better control (system instructions, temperature, schemas) but confusion over when data may be used for training; clarified that any account with a billed project gets private treatment.
    • Vertex: same models with higher, more negotiable rate limits.
  • Many dislike Gemini’s chat UX and file-handling; want native Git/FTP/file integration instead of copy-paste.

“Thinking” mode and behavior

  • “Thinking” is described as scratchpad / chain-of-thought tokens before the final answer. It improves quality but adds latency and lots of tokens.
  • Users question the value of a “thinking” variant that’s weaker than regular Flash, and some see no need for thinking on latency‑sensitive tasks (voice, real-time apps).
  • Reports that Flash sometimes emits thinking tokens even when thinking budget is set to zero.

Pricing and “bait‑and‑switch” concerns

  • Major point of contention: 2.5 Flash price changes vs preview and vs 2.0 Flash:
    • Input text/image/video: 2x increase over 2.5 preview (and higher than 2.0).
    • Output: single $2.50/M rate replaces $0.60 (non-thinking) and $3.50 (thinking); effective 4x increase for prior non-thinking use.
    • Audio for Flash-Lite up ~6.3x over 2.0 Flash-Lite.
  • Many see this as a “bait‑and‑switch”: developers built on cheap preview pricing, then face steep increases as models go GA.
  • Others argue earlier pricing was clearly subsidized to gain adoption; as Gemini becomes competitive, it converges toward market rates.

Limits, reliability, and access issues

  • Complaints about:
    • Low default rate limits (e.g., 10k RPD), opaque upgrade process, getting 403s mid‑batch; some moved back to OpenAI for throughput.
    • Empty responses or loops (e.g., Flash-Lite repeating phrases in transcripts), often tied to length limits or safety filters.
    • 2.5 Pro being unavailable or tricky to access via some API endpoints.
  • Some note that Vertex alleviates many rate-limit issues and offers more formal throughput guarantees.

Cloud vs local models

  • A few users consider local LLMs due to API pricing and limits, but others argue:
    • Hardware costs and rapid model churn make local generally worse economics unless you’re processing huge volumes.
    • Quality gap: local models on 24–48GB GPUs are closer to Flash-Lite level while being slower than top hosted models.
  • Local is framed as mainly for hobby and privacy, not efficiency—at least for now.

General sentiment

  • Many have shifted primary usage from ChatGPT/Claude to Gemini (especially 2.5 Pro and 2.0/2.5 Flash) and are impressed by speed, multimodal capabilities, and long context.
  • At the same time, there’s strong frustration about:
    • Perceived “nerfs”/quantization, particularly in the consumer app.
    • Overly cheerful, verbose tone.
    • Sudden price hikes and confusing thinking/non-thinking semantics.
  • Overall, Gemini is seen as technically strong and rapidly improving, but trust is undermined by pricing moves, behavior changes, and product fragmentation.

Windows 10 EOL

E‑waste and Windows 11 hardware cutoff

  • Many see the Windows 10 EOL plus Windows 11’s hardware requirements (TPM, CPU list, GPU features) as a major e‑waste driver, especially for organizations dumping tens of thousands of still‑usable PCs.
  • Others argue individual phone/laptop waste is physically small, or note that many orgs already refresh hardware on 3–5 year cycles, so the impact is overstated.
  • Some point out hypocrisy when people complain about e‑waste but themselves buy new Windows 11 machines instead of upgrading or switching OS.

Security and running an unsupported OS

  • Strong view: an internet‑connected, unsupported OS is “not tenable”; companies often mandate active support because most attacks exploit known, patched bugs.
  • Counterview: the box doesn’t “explode” at EOL; some users happily freeze on old builds and accept risk.
  • Detailed discussion of infection vectors: browser exploits (including Spectre‑style), malicious images/video, media decoders, NAT slipstreaming, IPv6 misconfigurations, and kernel‑level packet bugs. Risk rises sharply once modern browsers drop support.
  • For lightly used legacy apps, people suggest:
    • Disconnecting from the internet,
    • Or running Windows 10 in an isolated VM and avoiding web/file exposure.

LTSC / IoT and bypasses

  • Windows 10 IoT Enterprise LTSC is supported to 2032; some advocate using LTSC (often with unofficial activation tools) to extend lifespan.
  • Caveats: LTSC omits components some software expects; licenses are pricey; and “normal” Windows 10 support still ends 2027.
  • TPM/CPU checks for Windows 11 can be bypassed via command‑line flags or registry hacks, though this is unofficial and may break on future updates.

Apple vs Microsoft on obsolescence

  • Several note Apple also drops OS support aggressively, especially for Intel Macs, and older Macs can become unusably slow or blocked from current software.
  • Others counter that iPhones get longer support, and some Mac laptops still receive security updates for a decade‑old generation.
  • Overall sentiment: both vendors contribute to e‑waste, but Microsoft’s impact is larger due to Windows’ market share.

Telemetry, ads, and “enshittification”

  • Strong resentment of Windows 10/11 telemetry, built‑in advertising, and things like Copilot silently appearing.
  • Some commenters link aggressive security posturing (TPM, cert lifetimes) to broader trends of surveillance and adtech, arguing real‑world malware more often comes via ad channels than via exotic CPU attacks.

Linux as an escape route

  • Many recommend Linux for repurposing “unsupported” PCs, especially for home use, labs, and refurb markets; cheap ex‑corporate desktops/laptops are praised as excellent Linux boxes.
  • Others highlight real barriers: specific Windows‑only apps (e.g., WinForms development, niche accounting software), corporate environments, and gaming.
  • Desktop fragmentation is debated: some think Linux needs a more unified DE story to win “Windows 10 refugees”; others see choice and forking as inherent and desirable. KDE and Pop!_OS are mentioned as viable “refugee” options; Steam + Proton (and distros like Bazzite) make gaming workable for many titles.

Living with Windows 11

  • Several users describe “taming” Windows 11 via registry edits and third‑party tools (ExplorerPatcher, OpenShell, start‑menu tweaks) to restore older behaviors and remove web/search cruft.
  • Complaints persist about items Microsoft simply won’t allow (e.g., full tray icon control, web‑free Start), plus background “efficiency mode” throttling and forced updates.

Philosophical / misc. points

  • Some lament that Turing‑complete machines are being artificially “gated” by vendor policies, contrary to early computing ideals.
  • Others respond that no one is obliged to maintain software for old hardware; users are free to install alternate OSes (Linux, BSD, ChromeOS Flex, etc.).
  • A few see the Windows 10 EOL as an opportunity: cheap second‑hand hardware for enthusiasts, and a moment for Linux desktops to make a stronger pitch.

Honda conducts successful launch and landing of experimental reusable rocket

Comparison to SpaceX and Existing Launchers

  • Many see this as analogous to SpaceX’s early “Grasshopper / Starhopper”-style hops: a small tech demonstrator, not yet an alternative to Falcon 9 or other orbital systems.
  • Commenters emphasize that the rocket went only ~300 m, far from orbital-class reuse; several note 1990s DC‑X tests and multiple Chinese test vehicles as prior art for such hops.
  • Consensus: this is not “competition to SpaceX” yet, but a foundational step that could shorten Honda’s path if they pursue orbit-capable vehicles.

Scale, Role, and Seriousness of the Honda Vehicle

  • Specs discussed: ~6.3 m tall, ~85 cm diameter, ~900 kg dry / ~1,312 kg wet – essentially “car-sized.”
  • Many infer it’s a pure R&D platform for control algorithms, propulsion, and landing gear, not part of a defined commercial launcher family.
  • Honda’s own press language (still in “fundamental research phase,” no commercialization decision) reinforces that this is exploratory engineering and possibly talent development.

Why Reusable Rockets Seem “Easier” Now

  • One camp argues nothing is actually easy: only SpaceX has routine first-stage reuse after orbital missions; others (Rocket Lab, Blue Origin, several Chinese firms) are still catching up.
  • Another camp stresses enablers:
    • Proven feasibility (psychological / investor shift, “4-minute mile” analogy).
    • Better simulation, CFD, and in-house tools for engine design and control.
    • Advances in throttling (e.g., injectors, combustion stability) and manufacturing (3D-printed copper channels, improved tooling).
  • Several point out economics and risk appetite: government contracts, self-insurance, and “test on customer flights” strategies were pivotal for SpaceX; traditional agencies and incumbents remain more risk‑averse.

Market, Competition, and Strategy

  • Some expect more entrants now that reusability is proven, eventually eroding any one provider’s dominance, drawing analogies to past tech markets (servers, search, EVs).
  • Others counter that national security, subsidies, and institutional inertia keep legacy expendable programs alive; reusability is not yet an “extinction-level event” for them.
  • Honda is widely viewed as unlikely to become a full launch provider soon; this is seen more as high-end R&D than a near-term commercial play.

Tech Details and Propellants

  • The clean exhaust plume prompts speculation about hydrolox or methalox; commenters note Honda’s prior hydrogen work but agree details are unclear.
  • Observers highlight the smooth, continuous-burn landing and compact legs, comparing the aesthetics and mechanics to earlier VTOL prototypes.

Honda Brand, Culture, and .honda TLD

  • Many react with amused surprise that “Honda” and “reusable rocket” now coexist—but also recall Honda’s jets, robotics (ASIMO), motorsports, and even biotech research.
  • The .honda top-level domain sparks a side discussion about brand TLDs, ICANN’s fee-driven expansion, and companies’ increasingly fragmented domain strategies.

Timescale Is Now TigerData

Rebrand rationale and scope

  • Commenters note that the company position is: “TimescaleDB” remains the time‑series extension, while the company/cloud become “TigerData/Tiger Cloud,” reflecting broader workloads (many not time-series).
  • Some agree this makes sense to avoid being pigeonholed as “just time series,” especially with growing emphasis on vectors / pgvectorscale.
  • Others say they only care about the company for time-series, view the broader positioning as unwanted “pivot” energy, and are wary of “agentic era/AI” language.

Name choice and confusion

  • Many think “Timescale” was a much stronger, clearer brand; “TigerData” is seen as generic and cheesy.
  • There is heavy concern about name collisions and confusion with TigerBeetle, TigerGraph, WiredTiger, Tigris Data, and even non‑DB “Tiger…” brands.
  • Some initially assumed an acquisition/merger with TigerBeetle or influence from Tiger‑named investors.
  • A few offer alternative name ideas (e.g., keeping “scale,” different animal, taxonomic names) and argue they’d have preserved more brand equity.

Tone and marketing criticism

  • Several push back on blog claims that MongoDB, Cassandra, InfluxDB, etc. are “technical dead ends” and that “the Lakehouse has won,” calling this overstated, illogical, or pure marketing.
  • Referencing and “gloating” about an old skeptical HN comment is seen by some as immature and bad style, even if framed as historical skepticism.

Comparisons with other databases

  • Debate around InfluxDB: some say 1.x/2.x rewrites and language churn burned them; others (including Influx employees) defend 3.x and promise better migration tooling.
  • Timescale/TigerData staff argue they’re “Postgres on steroids”: good transactional guarantees, joins, a single SQL database for both OLTP and analytics, and competitive performance in their own RTABench versus ClickHouse.
  • Critics note Timescale doesn’t win in ClickHouse’s benchmarks; others say benchmarks differ by workload and point to DuckDB as interesting but single-user.

User experiences and operational concerns

  • Several positive long‑term production stories: reliable at scale for industrial metrics, easy continuous aggregates/retention, nice hosted/vector experience.
  • Some complain about needing deep expertise to get good performance on older data, tiered storage limitations (especially on Azure), and fear any non‑technical rebrand change in a core dependency.

Culture and branding reactions

  • Internal “tiger cubs,” “jungle,” and “Tiger Time” language is widely described as cringe or forced “fun,” though a few see it as harmless cultural flair.

Now might be the best time to learn software development

Overall reaction to the essay

  • Many found the piece funny, refreshing, and a useful antidote to AI doomerism about developers.
  • Some disagreed with specific framings (e.g., scale of productivity improvement) but broadly agreed that AI shifts the role of developers rather than erasing it.

Historical analogies: Fortran, COBOL, SQL, “no‑code”

  • Commenters drew parallels to past “anyone can program now” waves: Fortran, COBOL, SQL, QUEL, UML tools, FrontPage, Delphi, Flash, Dreamweaver, Excel, node-based tools.
  • Pattern noted: tools do raise productivity and broaden who can “program,” but:
    • They don’t eliminate demand for serious developers.
    • They eventually hit inherent limits; hand-written code (or more general tools) outlasts many of them.
  • SQL is highlighted as a partial success: many non‑programmers use it, but many developers still struggle and hide behind ORMs.

Farming, photography, and Jevons-style economics

  • The combine-harvester analogy split opinion:
    • Some see LLMs as similar: one dev can do the work of many; specialization around the core activity will expand.
    • Others say Fortran was a bigger productivity leap than current AI.
  • Debate over Jevons: food demand is partly inelastic, but waste and diet shifts suggest some elasticity.
  • Important distinction: farmers historically owned the capital; most developers are employees, so owners may capture more gains.
  • Photography analogy:
    • Digital cameras massively increased quantity and lowered entry barriers, creating more good photos and more competition.
    • Professional photographers’ income and job security declined; “good enough” flooded the market.
    • Some see this as a template for software: more apps, more “ok” work, tougher economics for pros.

LLMs in current software practice

  • Many report genuine productivity boosts:
    • Navigating large unfamiliar codebases.
    • Generating boilerplate, tests, deployment scripts, and reports.
    • Turning “I know what to do but not where/how” into concrete steps.
  • LLM-produced “vibe-coded” apps are already creating cleanup work; Upwork has clients stuck in AI‑generated pits.
  • Several compare LLMs to an overconfident junior dev: good at scaffolding, bad at edge cases and refactors; needs supervision.
  • Agentic/“fire and forget” coding is widely seen as unreliable; treating AI as an assistant, not an autonomous coder, works better.

Learning, Stack Overflow, and fundamentals

  • Many see this as a uniquely good time to learn programming:
    • LLMs fill the old “friendly Stack Overflow” role: tutoring, debugging help, alternate explanations.
    • They make early learning less lonely and more interactive; you can learn by debugging AI output.
  • Strong warnings not to skip fundamentals: without mental models (performance, concurrency, security, data structures), you can’t judge or fix AI output.
  • Several lament Stack Overflow’s decline and worry about the training data pipeline if fewer people share solutions publicly.

Psychological impact: support vs drain

  • Some find LLMs provide valuable “psychological support”: a rubber-duck partner that breaks procrastination and keeps momentum.
  • Others find them emotionally draining—“overconfident idiot” or “yes‑man” interactions that require constant correction, with no real pushback or insight.
  • People compare this to bad Google results vs. bad AI; both can be exhausting in different ways.

Jobs, wages, and prompt engineering

  • There’s visible anxiety: recent layoffs, worse interviews, talk of “productivity and cost reduction” from management.
  • Disagreement on actual unemployment levels, but consensus that perception matters more than theoretical productivity arguments.
  • Debate over whether prompt engineering will:
    • Become a high‑paid specialization (if value and scarcity are high), or
    • Be low-paid because barriers to entry are low and many can do it.
  • Some suggest reskilling outside software as a pragmatic hedge; others argue this is also a rare window for bootstrapped AI-era startups or building portfolio projects.

Labor power, efficiency, and distribution

  • Several note that productivity gains don’t automatically flow to workers; they hinge on power, organization, and policy.
  • Discussion around unions: tech is largely non-union, making it easier for firms to use AI as a pretext for wage suppression and headcount cuts.
  • Others counter that individual resistance (refusing hype, careful tool choice) is possible but weaker than collective action.

Skepticism about long-term AI programming dominance

  • Multiple commenters caution that most “this is the future of programming” predictions in history have been wrong.
  • Even if LLMs remain useful, particular tools and workflows (like past RAD tools) may fade, so betting an entire career on one AI stack is seen as risky.

Why JPEGs still rule the web (2024)

Why JPEG Still Dominates

  • Patent‑free, universally supported, “good enough” quality, and extremely fast to encode/decode. Hardware and software JPEG decoders are trivial compared to newer formats.
  • Huge existing corpus means everyone must support JPEG anyway; once you must keep it for compatibility, many see little benefit in switching for new images.
  • Ongoing encoder improvements (mozjpeg, jpegli) squeeze another ~5–15% compression and better perceptual quality out of the same old bitstream, narrowing the value of new formats.

WebP: Technically Fine, Socially Fractured

  • Some report that on modern Windows and Linux desktops WebP “just works” (Explorer, Paint, GIMP, etc.).
  • Others say “nothing supports WebP”: many upload forms reject it, CDNs and thumbnailers don’t handle it, major tools (e.g., Google Docs, some editors, video software) lack full support. GitHub and various web services still don’t accept it natively.
  • Backends frequently auto‑convert user JPEG/PNG uploads to WebP, sometimes re‑encoding lossless inputs to larger, worse lossy WebPs; repeated lossy transcodes cause visible generation loss.
  • Users resent not being able to easily reuse images (presentations, social media, simple viewers), and some have disabled WebP in browsers or resort to screenshots.
  • Security concerns noted: large, complex libwebp codebase has already yielded serious exploits.

AVIF, HEIC, JPEG 2000, JPEG XL

  • AVIF: good compression, but encoders are slow, CPU‑heavy, and can blur fine detail or mishandle dark scenes; support for 10‑bit and 4:4:4 is patchy.
  • HEIC/HEIF: technically solid (HDR, >8‑bit) and widely used by iPhones, but patent‑encumbered and inconsistent in practice (Windows decoding performance, HDR quirks, licensing worries).
  • JPEG 2000: better artifacts than JPEG, used in digital cinema and some archival workflows, but historically patent‑minefield, computationally heavier, poor browser support.
  • JPEG XL: widely praised in the thread as the best all‑round successor (lossless JPEG transcoding, HDR, extra channels, good performance), royalty‑free, supported system‑wide on recent Apple and Windows versions.
    • Chrome added then removed support, officially citing low usage; many commenters see this as Google protecting WebP/AVIF. Firefox is waiting on a safe Rust decoder.

PNG, GIF, and Use‑Case Splitting

  • Consensus: JPEG for photos; PNG (or SVG) for UI, line art, transparency, and exact color; GIF mainly legacy for simple animation.
  • PNG is lossless and ideal where fidelity or sharp edges matter; JPEG’s YCbCr/lossy pipeline makes exact color matching and crisp text harder.

Broader Pattern: “Good Enough” Wins

  • Many compare JPEG to MP3, ZIP, and H.264: technically surpassed but entrenched by ubiquity and tooling.
  • Newer formats (Opus, AV1, JPEG XL, AVIF) often win in labs but face inertia, patents, political battles (especially around Chrome), and fragmented real‑world support.

O3 Turns Pro

Perceived strengths and weaknesses of o3 / o3‑pro

  • Widely seen as higher‑quality, “system 2” / deliberate reasoning compared to fast models; good at holding state across fragmented prompts and large, messy contexts.
  • Major downside is latency (often 10–20 minutes); several people say this makes it unusable for iterative coding, but acceptable for deep analysis.
  • Some commenters find it worse or “really bad,” preferring to avoid it entirely; others put it at the top of their personal trust hierarchy for confabulations.
  • Compared against peers:
    • Often considered better than Claude Opus at catching subtle issues, but more prone to false positives.
    • Gemini sometimes seen as more contextually reliable and with fewer hallucinated bugs.
    • 4o is preferred for “people-parsing” and fast, nuanced text tasks.

Use cases where slow reasoning is worth it

  • Long‑form research reports and strategic analysis (e.g., startup landscapes, PE targeting, life decisions).
  • Large‑scale code review across many files/services, where thoroughness beats speed.
  • Complex JSON/data extraction with high correctness requirements.
  • Legal workflows: parsing who’s who in complex email threads; some report o1‑preview or 4o still doing better for this.

Reliability, hallucinations, and “deep research”

  • Deep research / web‑grounded tools are praised for detailed, up‑to‑date reports and source aggregation, but repeatedly described as “starting points,” not authoritative answers.
  • Users note subtle errors, missing key actors in domains they know well, or relying on SEO winners; cross‑checking sources is considered mandatory.
  • Skeptics argue that if you must verify everything anyway, direct search is simpler and more transparent.

Coding and multi‑model workflows

  • Common pattern: send the same problem to multiple models (e.g., 4o → Gemini → o3‑pro) and synthesize their answers, sometimes even having one model evaluate the others.
  • Some use o3‑pro in tools like Cursor specifically because it respects project structure and types better than faster models.
  • Others find o3 flaky at basic edits/commands and favor Claude Code for autonomous implementation from ticket lists, with o3 as an independent auditor.
  • Adjusting “reasoning effort” is reported to significantly change quality on reasoning models.

Latency, UX, and modality

  • Several say chat UX clashes with 10–20 minute replies; an email‑like, long‑form correspondence model is proposed as a better fit for o3‑pro.
  • Some note that o3‑pro has recently become somewhat faster, but still far from interactive.

Environmental and ethical considerations

  • A subset worries about energy use when hitting multiple models per query; others treat it like streaming in 4K or air travel—acknowledged but not behavior‑changing.
  • Debate on whether users should factor climate impact into everyday usage, versus pushing responsibility onto model providers.

Broader AI/AGI and profession impact

  • Skepticism that current systems qualify as “AGI,” pointing out visible impact mostly on developers and content creators, not yet on roles like sales, accounting, law, or teaching.
  • One commenter frames adoption decisions as cost/benefit rather than “trust,” using LLMs for work that isn’t worth a human’s time to perfect.

The hamburger-menu icon today: Is it recognizable?

Overall sentiment about the hamburger icon

  • Many commenters dislike hamburger menus, calling them lazy design, “junk drawers,” or “last resort” navigation.
  • Others argue that, after a decade of use, the icon is now broadly recognized by many users and functions adequately as a de‑facto standard.
  • Several note that both can be true: familiarity has increased, but it remains suboptimal for discoverability and clarity.

Cognitive load, recognition, and learnability

  • Icons require users to decode symbols, whereas text like “Menu” communicates more directly; multiple people report older or less tech‑engaged users not understanding the icon at all.
  • Some argue that frequent exposure lets icons approach words in efficiency; others counter that reading is heavily practiced from childhood while icon vocabularies are ad‑hoc and inconsistent.
  • Variants (three bars vs three dots vs “grip” handles vs gears vs logos) increase confusion and cognitive load.

Discoverability and “junk drawer” problem

  • A common complaint: hamburger menus hide key actions, leaving users unsure what exists or where it lives.
  • Items inside are often a disorganized mix of navigation, settings, and stray features; the menu becomes a dumping ground rather than a coherent structure.
  • Cited NN/g research (and other experience) indicates hidden navigation significantly reduces content discoverability and conversions.

Placement and consistency

  • Strong disagreement about “standard” placement: some say top-left, others observe it more often in top-right; a few advocate bottom or OS-standard buttons.
  • Several stress that inconsistency across apps (placement, contents, even meaning) is a core usability problem.

Text vs icons and localization pressures

  • Many advocate labeling the hamburger with “Menu” or using the word alone; others point out localization, word length variability, and layout constraints.
  • Counterpoint: if the UI already has translated text, one more word is a small additional cost.

Mobile vs desktop and broader UI trends

  • Many feel hamburgers are defensible on phones (limited space) but unjustifiable on desktops, where menus and toolbars offer better, denser, more discoverable controls.
  • Broader frustration appears around modern “flat,” low-density, icon-only UIs, removal of classic menu bars, and prioritizing aesthetics or cross-platform uniformity over usability.

Just How Many More Successful UBI Trials Do We Need?

Scope and quality of UBI trials

  • Many commenters argue existing “UBI trials” aren’t truly universal: they’re small, targeted (often unemployed or low-income only), short-term, and participants know they’ll end, which likely dampens behavioral changes (e.g., quitting jobs, moving).
  • Reported effects from cited studies: modest reductions in hours, some shifts to part-time, small drops in employer pay. Critics say this is insufficient to extrapolate to permanent, nationwide UBI.
  • Some call the article’s framing (“many successful trials”) misleading given these methodological limits.

Definitions and existing analogues

  • Strong insistence on distinguishing:
    • UBI: universal, unconditional, individual cash.
    • Means‑tested welfare / Guaranteed Minimum Income / EITC: targeted or conditional.
  • Pensions are cited as a de facto “UBI by age”: huge datasets show people largely stop working once eligible, pushing up dependency ratios; skeptics see this as a warning for UBI.
  • Others cite current welfare and tax credits as partial analogues that did not collapse work incentives.
  • Native American payments are raised as a “long-running UBI”; a reply argues dispossession and isolation, not payments, explain outcomes.

Inflation, rents, and price dynamics

  • Core worry: if everyone gets, say, $1,000/month, landlords and other sellers will capture it via higher prices; some claim UBI is useless without strict price controls.
  • Counterpoints:
    • If funded by higher taxes and replacing other benefits, total money supply need not rise; inflationary impact could be limited.
    • Housing prices depend on supply constraints, not just cash; UBI could enable moves to cheaper areas, making demand more elastic and potentially lowering rents in expensive cities.
    • Discussion of existing landlord collusion, zoning limits, and historical examples (e.g., removed toll → higher rents).
    • COVID cash transfers and student loans are cited as real-world examples of demand subsidies translating into higher prices.

Funding and tax structure

  • One camp: UBI is “something for nothing” and arithmetically impossible at meaningful levels; any real scheme is just rebranded welfare financed by taxing workers more.
  • Others propose flat-tax + UBI systems that are revenue-neutral but progressive in effect, with major simplification and replacement of many existing programs.
  • Practical concerns: multi-trillion annual cost, impact on social security, and whether higher earners would keep working enough to sustain the tax base.

Labor supply, incentives, and culture

  • Some assert that generous UBI would cause many, especially well-off, to stop working or avoid unpleasant but necessary jobs, threatening infrastructure and services.
  • Others counter that people with savings already could live off investments but still work; UBI mainly raises the floor from “work or starve” to “work if it’s worth your time,” shifting people toward education, entrepreneurship, or better jobs.
  • There’s a side debate over whether existing “non-working classes” or pensioners generate valuable cultural output, and whether expecting a creative renaissance from UBI is realistic.

Automation, post-scarcity, and timing

  • Several see UBI as part of a future, robot-run, post-scarcity economy; argue it’s premature now given ongoing reliance on “shit jobs.”
  • Others note AI is already displacing junior/administrative roles, and some redistribution mechanism will be needed; UBI trials should therefore be scaled up and taken seriously.
  • A skeptical view: automation will concentrate control and make most people economically irrelevant rather than naturally producing a shareable surplus.

Public goods vs. cash transfers

  • Some prefer prioritizing universal healthcare, education, housing, and transit over UBI, arguing these build real security, reduce complexity, and avoid inflationary cash transfers.
  • Concern that UBI will be used politically to justify cutting public services, creating a dystopia of weak social infrastructure plus small stipends.
  • Others respond that in places already hostile to public provision, UBI may be the only politically feasible way to improve security; a society with poor services + UBI is still better than poor services + no UBI.

Alternative designs and control risks

  • Proposal: instead of UBI, use central bank digital currencies to give everyone credit lines earmarked for food, rent, healthcare, etc.
  • Critiques: this turns benefits into debt, increases surveillance and behavioral control, centralizes power, and excludes those without IDs or banking access; seen as “digitized welfare,” not a new paradigm.

Gender, autonomy, and interpretation of results

  • A study showing larger autonomy gains for women is described in the article as driven by gender inequality (pay gaps, care burdens).
  • One commenter objects this is speculative for the specific, childless minimum-wage sample; labels it an ideologically driven explanation that might block exploration of other causes.

Macro outcomes and feasibility

  • Some argue that in any closed currency area, a true, livable UBI for everyone has never been attempted; small-scale successes say little about full-scale dynamics.
  • Others emphasize that productivity growth means societies can, in principle, support some people not working; the debate is over distribution, not physical feasibility.
  • A recurring theme: UBI supporters see it as morally and socially necessary as work is automated; critics see economic incoherence or political impossibility.

Politics, morality, and meta-discussion

  • One view: empirical evidence won’t matter; political elites act in self-interest and won’t adopt policies that genuinely empower citizens.
  • Some see resistance to UBI as rooted in beliefs about who “deserves” support and in the usefulness of visible poverty for social discipline.
  • Meta-concern about Hacker News flagging of UBI/AI threads and the ability of small groups to suppress certain narratives, with implications for AI training data and “defining truth.”

No Hello

Context & Related Resources

  • Many commenters connect “No Hello” to older IRC norms like “Don’t ask to ask, just ask” and similar sites (“nometa”, “dontasktoask”).
  • Others reference classic “how to ask questions” docs and suggest a broader need for remote‑work etiquette guides.

Why “Hello-Only” Is Annoying

  • Main complaint: it forces an unnecessary multi-step handshake in an asynchronous medium (Slack, Teams, etc.).
  • Costs: extra interruptions, context switching, and delays when the actual question could have been included up front.
  • In time‑zone–distributed teams, multi-turn greetings can stretch a simple exchange across hours or days.
  • Some liken it to a TCP SYN without payload in a context where pipelining would be better.

Defenses of the “Hello” Ritual

  • Many see it as basic politeness or “phatic” communication: signaling friendliness and non-aggression, especially in Anglo cultures (“how are you?”) or high-context cultures.
  • Some explicitly use “hello” to check if the other person is present/available before investing effort in writing a long message, or to avoid being ghosted.
  • A few admit they do it as a self‑prompt: once they’ve said “hi” they’re forced to follow up.

Proposed Etiquette & Compromises

  • Common suggestion: combine greeting and content in one message: “Hi, [short context + question].”
  • Some responders simply reply “Hi, what’s up?” or just ignore lone greetings until substance arrives.
  • Others advocate polite education: after helping, explain why it’s better to include the question immediately, sometimes linking to “No Hello” in a status or wiki rather than sending it directly.
  • There is disagreement over ignoring “hello”-only messages: some see it as justified boundary-setting, others as rude or passive‑aggressive.

Cultural, Power, and Role Dynamics

  • Several note this pattern is more common in certain regions (e.g., India, parts of Europe, Africa, Latin America), often tied to norms where jumping straight to business is considered rude.
  • Managers and people‑oriented commenters emphasize adapting to others’ styles and not over-optimizing minor social friction.
  • Others argue that leaders should still guide better async habits because poor messaging patterns hurt team productivity.

Tooling & Automation Ideas

  • Some suggest client features or regex/LLM filters to suppress notifications for bare greetings or auto‑respond to them.
  • Others worry that agent-mediated communication will make interactions more annoying, not less.

KiCad and Wayland Support

KiCad’s stance and reactions

  • KiCad’s blog says essential features for its workflows (window positioning, cursor warping, multi-window coordination) are missing or unreliable under Wayland; they won’t debug Wayland-specific bugs and recommend X11.
  • Many commenters sympathize: cross‑platform GUI work is already hard, and Wayland adds platform‑specific complexity and regressions, especially for complex multi-window tools like CAD/EDA.

Wayland design: security vs capabilities

  • Wayland intentionally hides global window state and input from clients to prevent keylogging, clickjacking, and focus stealing.
  • This breaks long‑standing patterns: apps can’t freely position windows, read window coordinates, or warp the pointer; screen capture and synthetic input require special protocols and often user prompts.
  • Some argue this is the right long‑term security/UX direction and such behaviors were “broken by design” in X11; others say many legitimate workflows (multi-window tools, automation, accessibility, text expanders, screen recorders) are collateral damage.

Protocols, fragmentation, and compositor behavior

  • Wayland is “just a protocol”; behaviors live in many compositors (GNOME, KDE, wlroots-based, etc.) plus a growing pile of extensions (screen capture, toplevel-drag, window restore, new pointer-warp, color management, HDR).
  • Critics say this has produced fragmentation: features exist only on some compositors, in “staging” protocols, or behind non‑standard extensions; app authors must detect compositor capabilities and branch code.
  • GNOME is repeatedly called out as resisting or delaying certain extensions (window positioning, richer APIs), which then discourages app developers from investing in Wayland support.

X11, Xwayland, and the “next system”

  • Several see X11 as ugly but proven and fixable; others insist X.org is effectively unmaintainable and can’t realistically be modernized for DPI, VRR, HDR, color management, etc.
  • Xwayland is widely viewed as the practical bridge: most X apps “just work” under Wayland via Xwayland, though edge cases (e.g., KiCad’s cross-window cursor warping, remote X forwarding) still fail.
  • Some predict a third system or a cleaned‑up X (e.g., XLibre) may eventually displace both; others think Wayland will slowly accrete the missing 5–15% of desktop features.

User experience split

  • Positive reports: smoother rendering, fewer glitches, better HiDPI and gestures, less tearing; many users say their whole desktop (plus Xwayland apps) is stable.
  • Negative reports: broken input, shortcuts, multi‑monitor quirks, theming, accessibility, and professional workflows; some tried Wayland repeatedly over years and always had to revert to X11.

The magic of through running

Overall reaction to the article

  • Some readers found the piece pleasant but “zero‑calorie” — trivia-heavy without real insight or “magic.”
  • Others, especially Londoners, related strongly to Thameslink / Crossrail examples and appreciated the historical framing.

Elon Musk and “great man” transit fantasies

  • One thread imagines the impact if Musk had focused on mass transit instead of cars and tunnels.
  • Multiple replies argue this is pointless speculation and that Musk’s Hyperloop/Boring efforts contributed little (or were even a distraction from real rail).
  • Counterpoints stress he has successfully realized other “big ideas” (rockets, EVs), so dismissing him as incompetent is also wrong.
  • Several commenters push back on the idea of relying on one billionaire at all; transit should be systemic and political, not personal.

City case studies and through-running projects

  • London: Thameslink and the Elizabeth line are held up as transformative; people love the feeling of a “proper train” slicing across the entire city. Crossrail 2’s absence from the article is noted.
  • Munich: Split views. Some praise the S‑Bahn concept and car‑free life; others complain about the single central trunk’s fragility and weekend disruptions. The second trunk line (Zweite Stammstrecke) should add capacity but may worsen transfers with deep vertical circulation.
  • Other cities mentioned:
    • Tokyo as the “next level” of through-running with multiple private operators interlining seamlessly, especially airport links.
    • Sydney/Melbourne use central loops instead of pure through-running; Melbourne’s new tunnel will shift more lines to through service.
    • Auckland, Brussels, Boston, Prague and Kassel are cited as in-progress or historic examples, often highlighting high costs and complex geology or politics.

Cars, class, and urban form

  • One strong thread argues cars enabled lower- and middle-class homeownership far from jobs by turning long distances into manageable commutes.
  • Many rebut that:
    • Good rail can achieve the same or better (examples from Stockholm, Paris, French high-speed commutes).
    • Widespread car use creates congestion, so the “30 miles in 30 minutes” benefit collapses when everyone drives.
    • Externalities (pollution, road danger, sprawl) disproportionately harm poorer residents, who often own fewer cars yet live near busy roads.
  • Some claim elites want the poor on transit so roads are free for the rich; others counter that in healthy systems even affluent people prefer transit if it’s clean, safe, and frequent, with anti‑social behavior enforced against.

US governance, politics, and underbuilt rail

  • Commenters note many US cities became large after the 19th‑century rail boom, so adapting rights-of-way is more political than physical.
  • Fragmented agencies, two‑party gridlock, and transit-as-welfare attitudes undermine robust investment and through-running (examples: NY Penn, Philly, Boston, Bay Area systems).
  • In places like New York, capital spending is portrayed as patronage for unions/contractors more than rider-focused; fare enforcement is often lax, contributing to a sense of disorder.

Costs, modes, and alternatives

  • One commenter proposes dedicated “transit roads” with platooned electric buses as a cheaper, flexible alternative to heavy rail.
  • Others challenge their cost numbers, emphasize capacity per corridor rather than cost per mile, and argue rail’s skills gap and politics explain high US costs.
  • Guided busways and similar schemes exist but are said to struggle with throughput versus rail in dense cores.

Ticketing and user experience

  • Integrated ticketing is highlighted as crucial: UK cities outside London often require multiple tickets across modes, discouraging optimal multimodal trips.
  • Examples like Santiago’s time-based card with cheap transfers are praised as making through‑style movement much more practical.

Fossify – A suite of open-source, ad-free apps

Overview & Motivation

  • Thread centers on Fossify, an open‑source fork of Simple Mobile Tools, valued for being ad‑free, minimal-permission, and privacy‑respecting.
  • Many commenters use Fossify to replace stock/OEM/Google apps or the now‑“enshittified” Simple Mobile Tools apps.

User Experiences with Fossify Apps

  • Frequently praised apps: Gallery (rename/delete, EXIF stripping, no cloud push), Messages (simple, no spammy extras), Calculator (unit conversions), Calendar (non‑intrusive scheduling), Contacts (can store contacts invisible to other apps), File Manager, and basic utility tools (paint, recorder).
  • The Voice Recorder is repeatedly criticized as weak (low volume, reliability issues).
  • Keyboard is seen as OK but limited; lack of swipe typing is a notable gap.
  • Dialer works but has a confusing UX for emergency numbers: Android’s system UI takes over, so it appears as if nothing is happening even though the call connects.

Origins: Fork of Simple Mobile Tools

  • Fossify is explicitly identified as a fork created after Simple Mobile Tools was sold to ZipoApps.
  • Users report SMT Play Store apps now request more permissions, include trackers, ads, and even expensive weekly subscriptions (e.g., flashlight), with some calling them “effectively malware.”
  • Concern is raised about possible GPL violations because SMT’s GitHub appears stagnant while Play Store versions change.
  • Migrating requires reinstalling and reconfiguring; no automatic settings transfer, though F‑Droid users mainly just noticed SMT updates stopping.

Privacy, Ads, and the Android Ecosystem

  • Many see Fossify as a reaction to the growing ad/spyware problem: OEM and Google apps gaining nags (e.g., Photos backup prompts), telemetry, and AI bloat.
  • RCS “ads” via Google Messages and vendor SMS apps are a big motivator to switch, though some clarify these are spam messages, not in‑app banners.
  • Fossify is valued for being open source and not syncing data to Google, unlike stock apps seen as ecosystem lock‑in plus hidden tracking.

Calendars and UI Preferences

  • Debate around “month view”: one side calls it antiquated and limiting (especially around month boundaries); others insist it’s the most useful overview and should remain an option.
  • Some mention alternative designs (multi‑week, seamless scrolling) in other FOSS calendars as preferable.

Launchers and Keyboards

  • Desire for a simple, Pixel‑like FOSS launcher with minimal features and low overhead.
  • Fossify Launcher beta on F‑Droid is praised for simplicity and dense icon grids but reported to “lose” widgets intermittently.
  • Alternatives like Lawnchair and terminal‑style launchers are suggested.
  • Unexpected Keyboard is mentioned as another FOSS keyboard option.

Emergency Calls & Custom ROMs

  • One commenter warns about emergency‑call reliability issues as a reason to avoid heavy customization.
  • Others argue phones already fail in stock configurations and that custom ROMs are a response to that; reliability trade‑offs are acknowledged.
  • Suggestions include arranging test calls with local emergency services via non‑emergency numbers.

Alternatives, OSs, and Funding

  • Users mention running Fossify on LineageOS or /e/OS to avoid Google entirely.
  • /e/OS is praised for low bloat and F‑Droid integration but criticized for lagging security updates and small‑team limitations (e.g., camera quality issues).
  • Several people donate via the Fossify “Thank You” app but dislike keeping it installed; workarounds include removing it after donating or using F‑Droid builds.
  • There is interest in better collective funding structures for suites like Fossify.

Games & Broader Ad‑Free Desire

  • A side thread asks for similarly ad‑free games; suggestions include checking F‑Droid’s game category and specific titles with no ads or microtransactions.
  • Overall sentiment: Fossify exemplifies a growing demand for straightforward, local‑first, ad‑free apps in contrast to the increasingly commercialized mainstream app ecosystem.

Introduction to the A* Algorithm (2014)

Reposts and “evergreen” content on HN

  • Some complain the article is repeatedly reposted; others argue many readers are new and haven’t seen it, so resurfacing is valuable.
  • Criticism of “hall monitor” behavior around reposts; pointing out duplicates is seen as low-value status-seeking unless it fights spam.
  • Suggestions for better platform features: “evergreen” items that get resurfaced periodically, personalized by what a user has already seen.
  • HN search is noted as useful for finding old discussions, which may contain extra “nuggets” beyond the original post.

Why A and this article remain popular*

  • A* is viewed as the obvious first pathfinding algorithm to teach: easy to visualize, broadly useful, simple extension of BFS/Dijkstra.
  • Several note that A* isn’t emphasized enough in CS curricula despite its power and conceptual elegance.
  • Many attribute the link’s repeated popularity to the quality of the tutorial: strong visualizations, examples, and clear explanations.

A vs “realistic” behavior in games*

  • One commenter dislikes A* as a “performance hack” that makes entities behave omnisciently and unrealistically.
  • Others respond that:
    • The “unfairness” is really about what information the heuristic uses, not A* itself.
    • Games prioritize fun and performance over realism; “reasonable” paths often look better than optimal ones.
    • Human-like limitations can be modeled by hiding information (fog of war, incomplete graphs) or using non-optimal heuristics.
  • Discussion of alternatives and refinements: navmeshes, formation following, cohesion costs, and special handling (e.g., water crossings).

Relationship to other algorithms and mental models

  • Several people frame BFS, DFS, Dijkstra, and A* as essentially the same framework with different data structures or priority functions.
  • A common teaching pattern:
    • BFS → queue; DFS → stack
    • Dijkstra → priority queue by cost-so-far
    • A* → priority queue by cost-so-far + heuristic estimate
  • Emphasis that admissible heuristics must underestimate to guarantee optimal paths, though inadmissible ones can be useful for style or speed.

A as “traditional AI” vs modern “AI”*

  • Some recall when algorithms like A*, logic, and planning were core “AI” topics; now “AI” is often used to mean deep learning/genAI.
  • Discussion of the “AI effect” and how once-understood techniques (like A*) stop being labeled AI.
  • In teaching, A* is placed into a “traditional AI” bucket distinct from machine learning and data science.

Resources, nostalgia, and side topics

  • Strong praise for Red Blob Games in general, especially the hex grid article and interactive visualizations.
  • Multiple commenters share nostalgia: this specific tutorial was their first encounter with A* or a formative learning experience.
  • Brief mentions of pathfinding in unknown environments (SLAM, D* Lite, ML-based exploration) and more advanced techniques like bidirectional search and pattern databases.
  • Minor threads cover pronunciation (“A-star”), jokes about Sagittarius A*, and gripes about poor real-world navigation software.

Selfish reasons for building accessible UIs

Moral vs “selfish” motivations and legal pressure

  • Several comments reject the idea that accessibility must be justified selfishly; excluding disabled users is framed as equivalent to knowingly shipping bugs for only one group.
  • Others say legal risk is now a major driver: ADA expansion, thousands of state-level lawsuits, and the upcoming EU Accessibility Act are pushing companies to care.
  • Some argue this is still “artificial”: accessibility remains unprofitable in many business models and is pursued mainly to avoid regulators, not to gain users.

Business incentives, cost, and “compatibility layer” ideas

  • Strong disagreement over whether accessibility “pays for itself.”
  • One camp: designing with accessibility from the start usually improves UX for everyone, reduces later retrofit costs, and missing ~20% of potential customers plus lawsuit risk is bad business.
  • Other camp: even at design time it adds constraints, overhead, and seldom maximizes revenue; complex cases (e.g., data visualizations) clearly add extra work.
  • Some propose specialized accessibility software/“compatibility layers” (like Dark Reader, advanced screen readers, AI-based interpretive tools) as more efficient than demanding every site be perfect. Critics respond that this creates “ghetto systems” and still fails for unsupported sites.

Experiences of disabled users and state of the web

  • Blind and disabled commenters describe chronic exclusion: enthusiasm in early FLOSS efforts giving way to burnout as accessibility regressed (GNOME3, Wayland, modern web apps).
  • Many modern sites are described as effectively unusable with assistive tech, narrowing job opportunities and deepening the digital divide.
  • AI-based description tools are considered unreliable and even dangerous due to hallucinations.

Semantic HTML, “div soup,” and modern frontend practices

  • Many endorse semantic HTML (tables, buttons, labels, ARIA) as simultaneously improving accessibility, debugging, testing, keyboard use, and tools like Vimium/Shortcat.
  • Others stress that apps and documents differ, but still agree that replacing buttons/links with styled divs is harmful.
  • Debate over built-in controls: some say modern HTML primitives (date, dialog, popover, etc.) are now good and composable; others cite long-standing flaws (number inputs, select multiple, lack of real combobox) and argue complex apps need custom widgets.
  • Tailwind and heavy JS are criticized for creating unreadable “class soup” and opaque “JavaSludge” UIs, undermining both semantics and DevTools usability.

Culture, education, and human nature

  • Commenters blame the lack of accessibility education in standard curricula and OSS “scratch your own itch” culture.
  • There’s tension between views of humans as naturally empathetic vs. routinely selfish under capitalist incentives.
  • A recurring “selfish” argument: everyone ages into disability; accessible UIs are “future you” insurance.

Generative AI coding tools and agents do not work for me

Perceived productivity and review costs

  • Many agree with the article: reviewing AI‑generated code thoroughly often takes as long as, or longer than, writing it yourself, especially when you feel responsible for long‑term maintenance.
  • Several see AI agents as “interns with no memory”: they never accumulate project context, so every task restarts from scratch, unlike human juniors who learn over time.
  • Some argue skeptics are effectively choosing to keep very strict review standards; AI can be faster if you relax depth of review or accept more risk.

Where AI tools shine

  • Widely cited sweet spots:
    • Boilerplate and rote code (forms, React context/providers, Terraform tags, localization strings, simple scripts).
    • Debugging: explaining stack traces, finding likely causes, writing small targeted tests.
    • Navigating unfamiliar APIs or frameworks, especially when you already know how to judge the answers.
    • Reducing typing/RSI via autocomplete and tab‑completion.
  • Many use AI heavily for personal/toy projects and prototypes, but find it far less effective on large, old, or highly coupled enterprise codebases.

Workflow, prompting, and “AI coding” as a skill

  • Supporters stress that AI coding requires new skills: writing specs, breaking work into tasks, managing context (CLAUDE.md, AGENTS.md, rules files), designing workflows (spec → plan → stepwise implementation).
  • Some run multiple agents in parallel, have AI draft specs, or use it asynchronously (let it churn on low‑priority tasks while they do other work).
  • Others find this orchestration cognitively expensive, fragile across changing models, and question how transferable these skills will be.

Quality, testing, and risk

  • Commenters note studies: mixed or no productivity gains, more bugs, and potential cognitive downsides from offloading thinking.
  • Tests are seen as necessary but insufficient: they only spot‑check behavior and can’t guarantee correctness; AI can write superficial tests but struggles with deep test design.
  • Comparisons to compilers emphasize that LLMs are non‑deterministic and much less trustworthy; you must treat their output like untrusted third‑party code.
  • Some teams successfully use multiple AI code reviewers, finding real issues, while considering agentic code generation too risky.

Learning, cognition, and juniors

  • A recurring concern: heavy reliance on AI erodes problem‑solving skills and domain understanding, especially for juniors who never learn to code without it.
  • Others counter that reading/reviewing lots of code (including AI‑generated) can sharpen skills, and that AI can be a powerful teacher if used to supplement, not replace, thinking.

Economics, access, and polarization

  • Strong divide between people reporting 5–10x speedups (especially in CRUD/frontend work) and those who see near‑zero or negative ROI on complex, architectural, or safety‑critical systems.
  • Cost is debated: some say a few hundred dollars is enough to “get good”; others note this is significant for many, and argue employers—not individuals—should fund tools.
  • Several liken the debate to historic editor/IDE wars: some expect AI to become as standard as IDEs; others think its unreliability and review burden will cap its role.