Hacker News Reader: Top @ 2026-03-12 14:49:34 (UTC)

Consensus: Cautiously Optimistic — readers acknowledge nontrivial risk but many argue the aggregate size is manageable.

Top Critiques & Pushback:

• Relative size is small: Several commenters note $300bn is a modest share of total banking assets (roughly ~2.5% of lending) and not catastrophic on its face (c47351027).
• Concentration & contagion risk: Others point to concentrated exposures and capital ratios — e.g., Wells Fargo’s ~$59.7bn private‑credit lending equals a large fraction of its CET1 capital, and a concentrated loss (or a gated fund run) could be material for some banks (c47350667, c47351130).
• Modeling and rating skepticism: Users warned Moody’s estimates may understate tail risks, invoking past rating failures and highlighting cases like Tricolor/First Brands where bank losses occurred (c47351257, c47350957).
• Terminology & nuance: There’s pushback and clarification about what “private credit” means and whether bank lending to private‑credit firms equates to banks doing private credit themselves (debate between c47350977, c47351170, c47351348).

Better Alternatives / Prior Art:

• Stress tests & capital buffers: Commenters suggested the usual mitigants — stress testing and higher capital buffers to absorb concentrated losses (discussion referencing stress‑test thinking, c47351130).
• Monitoring nonbank counterparties: Several recommend closer supervision of banks’ exposures to NDFIs and transparency around funding lines to private credit firms (implicit across c47350667, c47350957).

Expert Context:

• Definition clarification: Helpful corrections note that “private credit” is typically non‑bank lending and banks are mainly financing those non‑bank lenders rather than replacing regulated bank lending (c47351170, c47350977).
• Fragility reminder: A commenter invoked historical fragility (Washington Mutual’s failure after a relatively small run) to caution that even modest losses can cascade if confidence evaporates (c47351257).

Consensus: Cautiously Optimistic — users like the idea and tooling but worry about privacy, provenance, and engineering trade-offs.

Top Critiques & Pushback:

• Privacy / uploading raw transcripts: Several commenters object to automatically uploading session transcripts to a third party and ask for clearer storage/access details (c47350914, c47351329).
• Dataset provenance & closed data: Some users questioned the claim of "1,573 sessions" and noted the dataset appears to be internal/closed, asking for more transparency or aggregated summaries (c47350804, c47350854).
• Over‑engineering for small scale: Multiple commenters said the stack (third‑party services) seems unnecessary for modest volumes and that simpler local processing can handle much larger datasets (c47350717, c47351305).

Better Alternatives / Prior Art:

• AgentsView / similar dashboards: A commenter pointed to agentsview.io as a related tool for agent monitoring (c47351232).
• Local log-analysis tools / pipelines: Others described local scripts or simpler storage (plain text, SQLite) and linked to open-source analyzers and personal pipelines that handle large token volumes cheaply (c47350877, c47350717).

Expert Context:

• Pipeline/gates idea: One commenter described a structured multi-stage agent pipeline (plan → design → code → review with gates) that improved first-pass acceptance from ~73% to >90%, and suggested Rudel’s session analytics could help evaluate which gates matter (c47350877).
• Skill usage & model differences: Discussion noted low skill invocation in some teams (~4%) and that prompting plus newer model versions (e.g., 4.6) changed skill invocation rates; some people explicitly instruct agents to call skills (c47350862, c47351112, c47351074).

If you want, I can extract key excerpts from the README and specific comments (with their full text) or produce suggested questions to ask the Rudel maintainers about privacy and data handling.

Consensus: Skeptical — commenters criticize the use of policing-style surveillance tools for school residency checks.

Top Critiques & Pushback:

• Misplaced priorities / waste: A top comment frames this as an example of spending on policing/monitoring instead of addressing root social problems and calls it an avoidable waste (c47351297).
• System purpose / unintended outcomes: A reply invokes the idea "the purpose of a system is what it does," implying the use of surveillance tech will produce outcomes aligned with monitoring rather than equitable access to services (c47351364).

Better Alternatives / Prior Art:

• None suggested in the discussion.

Expert Context:

• None provided in the comments.

Consensus: Cautiously Optimistic — users like the Unix-style, small-agent approach but want clarity on costs and real-world uses.

Top Critiques & Pushback:

• Cost control / fan-out risk: Concern that chaining or parallel sub-agents could be more expensive than a single large context, and users want guidance or safeguards (c47351292).
• Hidden session/state questions: People asked whether there is a "session" concept and how persistence works in practice; the project has persistent memory but users requested more examples of its semantics and limits (c47351134, c47351280).
• Perception of self-promotion: At least one commenter questioned whether the post read like an ad (c47351332).

Better Alternatives / Prior Art:

• ell (prompt-as-programs): Commenters compared Axe to ell, which similarly treats prompts/agents as small programs (c47351032).
• Local-model workflows: Several users noted appeal for local model users and Ollama integrations as an existing alternative for on-host, low-latency agents (c47351200).

Notes / Takeaways:

• Discussion is largely exploratory and positive; readers want usage examples, cost budgeting guidance, and more real-world automation stories from the author (c47351280, c47351292).

Consensus: Enthusiastic — commenters praise the clear, excited progress report and the big wins (Triforce return, Rogue Squadron speedups) (c47349757, c47350866).

Top Critiques & Pushback:

• ROM safety and provenance worries: multiple users asked about trustworthy ROM sources and malware risks; responders pointed to checksums/DATs and argued malicious ROMs are rare but archives/packaged downloaders can be risky (c47350158, c47350263).
• Where to donate / funding transparency: readers asked whether Dolphin accepts donations; moderators/users pointed to forum policy that Dolphin does not accept donations (c47349977, c47350128).
• Clarification on Triforce "IC Card": commenters explained these are arcade memory cards used for save data (IC/magnetic cards) and provided links/details for those unfamiliar (c47350968, c47351127).

Better Alternatives / Prior Art:

• ROM verification/databases: users recommend No-Intro/Redump/TOSEC DATs for checksums and CleanRip for making verified dumps; Archive.org was mentioned as a host for some GameCube ROMs (c47350253, c47350340, c47350292).

Expert Context:

• Practical clarification about Triforce saving hardware: commenters explained that Triforce games commonly use magcards and IC cards for persistent saves (useful context for why IC card emulation unlocks features) (c47351127, c47351142).

Consensus: Cautiously Optimistic—people like the “serious analytics on cheap hardware” message, but argue over what the benchmarks prove and whether 8GB is workable.

Top Critiques & Pushback:

• Cloud comparison is misleading without local-NVMe instances: Several argue the laptop’s “cold run win” is mostly about AWS using network-attached storage (EBS) rather than comparable ephemeral NVMe, so it’s not an indictment of cloud compute as such (c47349794, c47350145, c47349848).
• Skepticism about 8GB in real workflows: A long subthread fights over whether 8GB Apple Silicon machines stay smooth once you add browsers/Electron apps (Slack, Teams, lots of tabs) and modern OS/app bloat (c47350231, c47350452, c47360516).
• Benchmarking trust / apples-to-oranges worry: One commenter says a prior DuckDB “on mobile” post weakened their trust in the project’s benchmarking framing, though others rebut the specific claim (c47361448, c47362541).

Better Alternatives / Prior Art:

• Use AWS instances with local NVMe for fairer tests: Suggestions include c8gd and similar “d”/NVMe-backed types; also note ephemeral-NVMe is ideal for benchmarks if you can re-stage data (c47349848, c47350698).
• Polars vs DuckDB: Some report huge speedups or fewer OOM issues moving workloads to DuckDB; others note Polars is fast if used lazily and without Python row-wise UDFs (c47350369, c47352012, c47350732).

Expert Context:

• “Big data” definition debate: A teacher defines big data as “doesn’t fit on one machine,” prompting discussion that modern single boxes can have enormous RAM/disk, while others point out industrial telemetry can still hit petabyte/exabyte scales quickly (c47350369, c47353338, c47360943).
• Cloud cost vs flexibility nuance: Some call cloud “ludicrously overpriced” for compute/bandwidth, while others stress you’re paying for elasticity, speed of scale-up, and DR; debate centers on whether those benefits are real in practice (c47349952, c47350216, c47350786).

Consensus: Cautiously skeptical—people enjoy the satire but worry it’s close to (or already) reality.

Top Critiques & Pushback:

• “This isn’t clean-room (especially with LLMs)”: Commenters argue a true clean-room requires implementers with no exposure to the original code, which clashes with LLMs trained on vast public repos; they question how you could prove non-exposure or non-copying in court (c47353928, c47353606, c47357654).
• “Satire vs real service” confusion: Many initially read it as a real product; others insist it’s satire, while some note Stripe checkout appears real and claim the service actually generates code, making it “real but satirical” (c47351178, c47353127, c47358580).
• “Undermines OSS social contract”: Strong moral pushback that the pitch is parasitic—paying to avoid attribution/coplayleft rather than supporting maintainers—plus concern it normalizes behavior companies already attempt (c47353349, c47360798, c47353737).

Better Alternatives / Prior Art:

• Dual licensing / CLAs: Some point out maintainers can dual-license, but others note it’s impractical without contributor agreements/CLAs for many projects (c47356628, c47356759, c47360324).
• Traditional clean-room + reverse engineering precedent: People reference established clean-room approaches and scholarship on reverse engineering/implementation as a “safety valve” in copyright (c47355240, c47354142).

Expert Context:

• “Costs matter; enforcement changes policy” meta-thread: A large subdiscussion generalizes the idea: when technology makes enforcement cheap/perfect (surveillance, automated compliance, AI-generated legal demands), the effective policy changes dramatically and may require rewriting/simplifying law; others debate whether discretion is a bug (selective enforcement) or a feature (civil disobedience, pragmatic policing) (c47352848, c47353324, c47355140).
• Concrete near-term example (chardet): The chardet relicensing/rewriting controversy is cited as a real-world analogue, plus demonstrations that models can reproduce source verbatim from training/environment caches—undercutting “independent recreation” claims (c47354348, c47356000, c47357259).

Consensus: Cautiously Optimistic. Commenters largely agree trig is often unnecessary inside low-level geometric code, but note practical exceptions and tradeoffs (intuitiveness, input mapping, interpolation).

Top Critiques & Pushback:

• Angles are useful UI primitives: Many argue angles (pitch/yaw) are simpler and more intuitive for input, configuration, and simple use-cases like billboards or FPS controllers (c47349402, c47350925).
• Some problems legitimately use angles/trig: When an algorithm explicitly needs an angle (e.g., SLERP, dihedral angles, user-driven scalars) or when APIs expect angles, trig may be unavoidable; also watch for singularities and edge cases (c47349375, c47348939).
• Engineering tradeoffs: Over-optimizing away trig can complicate code and API design; clarity and maintainability sometimes justify higher-level angle-based abstractions (c47349541).

Better Alternatives / Prior Art:

• Rodrigues / direct algebraic forms: The article is essentially algebraic manipulation of Rodrigues' rotation formula to eliminate trig (c47349177, c47349371).
• Quaternions / spin groups / Householder transforms: Suggested as established alternatives for rotations that avoid many trig pitfalls (c47349375, c47349678, c47349270).
• 2D: unit complex numbers: Representing rotations as unit complex numbers avoids trig for many planar tasks (c47348702).
• Rational/alternative trig frameworks: Some point to Wildberger's "Rational Trigonometry" as a contrarian but related take on avoiding standard trig (c47348889).

Expert Context:

• Commenters highlight that this is mostly removing an unnecessary "round trip" (acos then cos) and that many trig identities are just vector identities restated; the algebraic simplification is mainstream and known (c47349371, c47349177).
• A performance/complexity note: computing dot/cross is a fixed small number of arithmetic ops, while high-precision trig can be much more expensive in theory (c47349954).

Consensus: Cautiously optimistic — commenters find the technology interesting and potentially useful, but many doubt it alone will stop overconsumption.

Top Critiques & Pushback:

• Doesn’t fix consumer behavior: Several argue on‑demand manufacturing won’t stop trend‑driven overconsumption — people buy for novelty, not just availability (c47348380, c47349359).
• Cost & scalability concerns: Commenters note current price points (example: $150–$200 mentioned) make these items comparatively expensive and question whether on‑demand can match mass production prices or scale to replace fast fashion (c47351299, c47350031).
• Quality and repairability skepticism: Users report that branded/expensive items still fail and that quality labeling is unreliable; some point out repair support varies (c47348606, c47350283).
• Could enable faster cycles: A few worry easier on‑demand/custom production might increase, not reduce, rapid fashion turnover if retailers exploit speed (c47351217).

Better Alternatives / Prior Art:

• Shima Seiki / Tailored Industry: Commenters highlight SHIMA SEIKI as the technology’s origin and point to platforms/businesses already using on‑demand 3D knitting (c47349132).
• Established retail uses: Uniqlo and other brands already offer limited 3D‑knit products, showing an existing commercial path (c47350500).
• Hand or traditional knitting: Some note hand knitting and established small‑scale production remain relevant for different use cases and yarn types (c47349132).

Expert Context:

• Production & business model angle: A commenter who'd interviewed companies using alternative yarns (seaweed) stressed the real innovation may be the business model and localized, low‑waste production/fulfillment — not just the machine itself (c47349132).

Notable threads & suggestions:

• Questions about machine cost and who bears it (c47350031).
• Interest in de‑knitting/repairability and finer/lace yarns as future directions (c47350965).
• Practical supply‑chain examples: used‑clothes markets and local resale businesses show how the clothing discard stream already supports other models (c47350210).

Consensus: Cautiously Optimistic — commenters mostly agree CI should catch mistakes, but many find the article’s headline and framing oversimplified.

Top Critiques & Pushback:

• Oversimplified framing / clickbait: Several commenters feel the headline understates CI’s longstanding role in preventing shipping bugs and is misleading (c47351333).
• Icon suggestion criticized: The proposal to invert colours (green for failure, grey for success) is seen as counterproductive; green-as-good and red-as-action-required is established and useful (c47351084).
• Rerun ≠ always flaky: Rerunning a passing run after a failure can hide real problems (e.g., concurrency or production-timing issues), not only flakiness (c47351347).
• Tests can be brittle or poorly designed: Concern that many unit tests are overly tied to implementation and force maintenance; good tests should be stable, verify behavior (not internals), and avoid excessive coupling (c47351221, c47351355).
• Coverage is not proof of correctness: Commenters warn that 100% coverage can be meaningless without meaningful assertions (Goodhart’s law) (c47351019, c47351363).

Better Alternatives / Prior Art:

• Shift test strategy: Some suggest favoring functional or end-to-end tests and focusing CI on the failure modes you most want to prevent, rather than maximizing superficial checks (c47351355, c47351221).
• Use CI for team coordination: Others emphasize CI’s value in enabling developers to build on partial work and keeping integration sane — not just bug-catching (c47351256).
• Formal methods mention: One commenter notes formal verification is the tool for proving correctness; tests primarily find mistakes (c47351320, c47350984).

Expert Context:

• Testing’s primary role: Multiple commenters reiterate a classical testing insight: tests show the presence of bugs, not their absence — CI’s usefulness comes from finding real mistakes, and flaky CI erodes that trust (c47350984, c47351347).

Consensus: Cautiously optimistic — commenters like the simplicity and personal-focus but see it as a niche, early-stage exploration rather than a mass‑market solution.

Top Critiques & Pushback:

• Usability & key management: Many worry ordinary users will lose keys or be unable to manage backups; localStorage for private keys is flagged as fragile and unforgiving (c47346261, c47346401). Commenters propose export buttons, QR backups, or Shamir sharing as mitigations (c47350584, c47346966).
• Not built for scale or network effects: Several argue the project intentionally targets small friend groups and won’t provide the viral/content dynamics that drive mainstream social apps (c47345671, c47347620). That limits its ability to "unseat big tech." (c47346730)
• Discovery/path conventions: People pointed out using a well-known URI (/.well-known/) would better signal protocol endpoints and avoid path collisions instead of the satproto_root.json fallback (c47350291, c47346132).

Better Alternatives / Prior Art:

• IndieWeb / Webmention / FOAF: Commenters note this overlaps with existing personal-website-based approaches (IndieWeb, Webmention, FOAF) and suggest looking to that ecosystem for ideas (c47346231, c47345880).
• AT Protocol / Mastodon / simple centralized alternatives: Users compared s@ to RSS+PGP and to AT Protocol or Mastodon, noting s@ is intentionally more peer-to-peer and friend-focused; others pointed to simpler username/password hosted solutions (e.g., Jonline) as more approachable for non-technical groups (c47346114, c47349719, c47347954).

Expert Context:

• Cryptographic trade-offs & mechanics: Several commenters clarified that the design is essentially PGP/RSA-like session-key envelope behavior applied to static files — content keys are shared by encrypting them to each follower’s public key (so key rotation requires re-encryption of stored ciphertexts), and this is what creates the practicality and scaling constraints (c47346114, c47346127, c47345671).

Overall, readers appreciate the clarity of the small‑group, static‑site approach and its low-dependency model, but the conversation centers on making key storage/recovery and UX robust, and on whether such a design can move beyond hobbyist use (see cited comments above).

Consensus: Skeptical.

Top Critiques & Pushback:

• Readability / UI taste: Multiple users find the Liquid Glass aesthetic hard to read and visually unappealing; commenters emphasize it feels too flashy or not faithful to Apple’s actual macOS glass (c47350993, c47350861, c47351175).
• Missing screenshot / first impressions: Early feedback repeatedly asked for a screenshot before trying it; the author later added one to the README (c47350631, c47350745).
• Why not existing tools?: Some asked why the author didn’t use tmux or stick with iTerm2, arguing those are mature alternatives and would be hard to replace (c47350940, c47351185). The author replied they wanted a translucent macOS-native UI and features Ghostty lacked (c47350277).

Better Alternatives / Prior Art:

• iTerm2: Frequently mentioned as the default power-user macOS terminal that would be hard to convince users to give up (c47351185).
• tmux: Suggested as an existing way to organize sessions and splits without building a new terminal (c47350940).
• libghostty / Ghostty: The project builds on Ghostty; commenters note compatibility and that Calyx aims to add missing workflow features while keeping Ghostty’s speed (c47350277).

Expert Context:

• Design fidelity note: A commenter pointed out that the repo’s Liquid Glass differs from Apple’s native effects (more blur/opacity needed) and that Apple itself hasn’t made a native glassy Terminal, suggesting a mismatch between inspiration and platform convention (c47351175).

Notable positives called out:

• Feature set: Commenters acknowledged the comprehensive feature list (tab groups, session persistence, search, Git view, IPC) and the convenience focus demonstrated in the README and demo (c47350277).

If you want, I can extract the README screenshot link and highlight specific feature implementation files in the repo.

Consensus: Enthusiastic — commenters praise SBCL’s performance, tooling, and active development while discussing practical and historical details.

Top Critiques & Pushback:

• Image vs source confusion: Several readers question whether image-based workflows can or should replace source files and worry about reproducibility or portability of image dumps (c47351285).
• Misunderstandings about tooling/names: Some confusion arose over a tweet claiming SBCL’s compiler was written in Python; commenters clarified CMUCL has a compiler component named "Python" (unrelated to the Python language), and the SBCL work involves Lisp, C and assembly (c47348288, c47348877, c47348487).

Better Alternatives / Prior Art:

• Other Common Lisp implementations: Commenters point to CMUCL, LispWorks, Allegro CL as related or proprietary alternatives and mention that SBCL builds on that lineage (c47348877, c47348796).
• Related Lisps and ecosystems: Racket/Chez Scheme, Clojure, and Arc are discussed as modern or production-used Lisp-family systems; Hacker News/Arc runs on SBCL (c47349473, c47348254, c47348471).

Expert Context:

• Production use-cases and performance: Several examples of real-world Lisp usage were cited: Hacker News/Arc on SBCL, Google’s ITA (Flights), pgloader’s rewrite speedup, and companies using Clojure — underscoring that Common Lisp and Lisps in general are used in production despite being niche (c47348471, c47348796, c47349448).
• Active development and features: Commenters note ongoing SBCL work (coroutines/fibers proposal, arena allocation, parallel GC, ports like Nintendo Switch), signaling continued investment in performance and systems features (c47347969, c47348206).

Consensus: Enthusiastic: commenters are impressed and amused by the cleverness, while a few note unease at how powerful format strings can be.

Top Critiques & Pushback:

• Not purely "one printf" — it uses scanf too: Several readers point out the program passes a scanf() call inside the printf arguments (so input is present despite the single‑printf claim) (c47351336).
• Format‑string power / security concern: Commenters found the technique impressive but “slightly terrifying,” i.e., a reminder that format strings can be extremely powerful and dangerous if misused (c47348904).
• Historical curiosity about %n: Users debated whether %n has always existed; one commenter traced early Unix sources and found %n absent or treated as invalid in some old implementations and present by System V R4, suggesting it was added later (c47349213, c47348590).

Better Alternatives / Prior Art:

• printbf: The README points to printbf (another project using printf/format‑string tricks) as related prior art and a natural thing to look at for similar curiosities.

Expert Context:

• Implementation history research: A commenter inspected PDP‑11/early Unix libc sources and reported %n wasn’t in Version 7 and appeared later (System V R4), providing useful historical context about when the writing behavior became available (c47349213).

(Also: a light, appreciative aside calling the program a kind of "One True Debugger" appears in the thread) (c47349883).

Consensus: Cautiously Optimistic — commenters appreciate Rails’ productivity and mature upgrade story but many fret about typing, maintenance, and hiring.

Top Critiques & Pushback:

• Lack of static types: Several readers argue large, dynamic Rails codebases are painful without typing; commenters note Sorbet helps but is less powerful than TypeScript and many prefer typed stacks for large teams (c47349759, c47349819).
• Dependency/upgrades and churn: People raised the familiar maintenance burden of older apps, transitive dependency pain, and how framework‑coupled gems (e.g. Devise‑like plugins) can make upgrades harder (c47347775, c47350301).
• Talent & ecosystem concerns: Some say Rails/Ruby have fewer active contributors and hiring is harder today, with many gems in maintenance mode even if Rails core still ships regularly (c47349774, c47351291).

Better Alternatives / Prior Art:

• Elixir / Phoenix: Frequently recommended as a modern, robust alternative (LiveView for interactive UIs), with multiple commenters sharing positive long‑running experiences (c47347503, c47348348, c47348424).
• Rust frameworks (Loco/Rust web stack): Mentioned as interesting newcomers that aim for Rails‑like ergonomics in Rust (c47349934, c47350491).
• Go / .NET: Several readers prefer simpler Go services or typed C# backends for maintainability and operational simplicity (c47347775, c47350959).

Expert Context:

• Rails upgrade stability praised: multiple commenters note Rails’ deprecation‑then‑removal cadence and upgrade documentation make upgrades less disruptive than many modern JS rewrites (example: Next.js router migration), so Rails can be easier to maintain if you keep up with deprecations (c47348580, c47351044).
• Real‑world Rails longevity: Several comments point to long‑running production Rails usage and productivity benefits, arguing that many businesses quietly continue to run Rails successfully (c47349609, c47347768).

Consensus: Cautiously Optimistic — commenters treat this as a sensible follow-up to earlier font-synthesis work but the HN thread is tiny and not deeply critical.

Top Critiques & Pushback:

• Minimal critical discussion in the thread; no substantive technical objections or failure cases were raised (c47308191, c47350693).
• One commenter frames the project as a direct follow-up to earlier zi2zi work, emphasizing the switch to a transformer backbone rather than a fundamentally new problem formulation (c47308191).
• Another comment is off‑topic, pointing to an old Cangjie/DOS-era utility and DOSBox usage, not to the repo itself (c47350693).

Better Alternatives / Prior Art:

• Original zi2zi (earlier neural font-transfer work) and JiT (the underlying diffusion-transformer) — both are cited in the repository.
• FontDiffuser — the repo borrows content/style encoder design and the evaluation protocol from this recent diffusion-based font generator.

Expert Context:

• The repo provides standard evaluation metrics (FID, SSIM, LPIPS, L1) on paired glyph grids and includes practical instructions for LoRA fine-tuning and fast samplers; the discussion mainly acknowledges it as an incremental, transformer-based continuation of prior work (c47308191).

Consensus: Cautiously Optimistic — commenters appreciate that Arca Noae continues to maintain and modernize OS/2 for existing users but question the market size and practicality.

Top Critiques & Pushback:

• Who is the audience / value proposition?: Several users question the commercial viability and price for a niche OS with limited modern application support (c47350535, c47350700).
• No access to original kernel source: Commenters note Arca Noae apparently does not have the original OS/2 kernel source and wonder why (licensing or lost code are suggested explanations) (c47350972, c47351211).

Better Alternatives / Prior Art:

• Niche OS ecosystems: One commenter contrasted ArcaOS with other small/nostalgia OS communities (example mention: MorphOS) as alternatives for hobbyists; eComStation/old OS/2 variants are also referenced as related projects (c47350535, page).

Expert Context:

• Possible reasons for missing source: A knowledgeable commenter summarized common explanations: third‑party code in OS/2 (making licensing difficult) or IBM having lost part/all of the source — this has been reported by Arca Noae staff in interviews (c47351211).

Notable Points & Anecdotes:

• Users expressed admiration that Arca Noae continues hardware support despite lacking original sources and shared nostalgic experiences running OS/2 in production and embedded contexts (ticket machines, banks) (c47350844, c47350741).

Consensus: Skeptical.

Top Critiques & Pushback:

• Dehumanization & first impressions matter: Many commenters say being screened by bots signals poor company culture or service and would deter them from applying (c47339362, c47344470).
• Asymmetric time cost: Users warn automation lets employers impose unlimited time/tests on applicants while spending little themselves — "full automation leaves them free to impose infinite cost" (c47340323, c47350169). Quote: "Full automation leaves them free to impose infinite cost with no guarantee of anything." (c47340323).
• Opaque evaluation & bias/accountability: Compared with objective online tests, AI interviews lack clear grading criteria and are harder to audit; commenters worry LLMs encode biases and companies won’t be accountable (c47347239, c47350372, c47349167).
• AI arms race and spam: Applicants also use AI to apply en masse, producing noisy pipelines; some suggest token-cost attacks or quotas as countermeasures (c47343926, c47340500, c47350119).
• Global and inequality impacts: Several note this will disproportionately harm applicants in regions or markets with few alternatives (e.g., India) and could entrench bad hiring practices (c47342293, c47348164).

Better Alternatives / Prior Art:

• Standard automated tests / take-homes: Some argue LeetCode/CodeSignal-style screens or short, well-designed take-homes (e.g., 20-minute tasks) with human follow-ups are preferable because they’re more transparent (c47344830, c47345144).
• Human referral / smaller shops: Inside referrals and hiring via smaller teams or direct manager review are suggested as practical ways to avoid over-automation (c47341248, c47343536).

Expert Context:

• Evaluation gap: Commenters highlight a core difference between deterministic tests (with explicit scoring) and LLM-based interviews: the latter can be inconsistent and inscrutable, making it difficult for candidates to know what was judged and for auditors to verify fairness (c47347239, c47350372).

Overall the HN thread is wary: people see some utility at scale but worry about transparency, fairness, time asymmetry, and cultural signals; many recommend keeping humans in the loop or using clear, auditable screening methods (c47344830, c47345144, c47341248).

Consensus: Enthusiastic — commenters like the creative glitch art and the site itself.

Top Critiques & Pushback:

• Not entirely novel / known technique: Several users point out this is a form of datamoshing/glitch art and link to prior resources (datamoshing, compression-artifact art) (c47347695, c47348447).
• Playback / compatibility quibble: One user reports the embedded video fails to play in their browser with a MIME/format error (c47349309).
• Mostly admiration, minor jokes: Comments are largely positive or playful (IKEA-name joke, praise for the site/community), not deep technical criticism (c47350209, c47347433, c47347354).

Better Alternatives / Prior Art:

• Datamoshing / ffmpeg tools: Commenters reference established glitching approaches and an ffmpeg-based fork for glitching (ffglitch-core) as related or alternative tooling (c47347695, c47348447).
• Raw YUV editing: The author tried editing raw yuv frames (adding noise) but found recompression inflated file size and reduced glitch effects — so while viable, it had practical downsides (from the page content).

Expert Context:

• Historical/practical context: Commenters point to the history of compression-artifact art (datamoshing) and an ffmpeg-focused glitching project, framing this work as a creative implementation within that tradition (c47347695, c47348447).

Notable Mentions:

• A commenter links to a blog post about “hexing” interviews as a tangential association (c47349450).
• Discussion also highlights the site's collective/DIY spirit and how people enjoy post-work creative projects (c47347354, c47347866).