LLM=True

I'm helping my dog vibe code games

Turing Completeness of GNU find

Meta has a problem in its clusters in Boca Raton, Miami; this is affecting the MNA content delivery network and direct content consumption. This has a regional impact in Latin America, since so far most non-cacheable content is consumed from the clusters in Florida.The impact is traceable via ICMP, but also reproducible via TCP and difficult to measure via UDP. This is why monitoring tools are misleading: there is no “slowness” resulting from interface saturation; instead, there is data corruption where packets are discarded at the interface level. Therefore, if network performance is measured using those same data points, it won’t work and you won’t see any alerts.The issue can also be replicated from the looking glass. In fact, I will attach images below, although you can also see them on the website attached to the post, as well as a more specific reportThere is packet loss and probably flapping on a BGP instance, OSPF, or some IGP within Meta’s network. I believe it is between 129.134.101.34, 129.134.104.84, and 129.134.101.51. It is possible that it’s a faulty interface in a bundle or some hardware issue that a “show interface status” doesn’t reveal, which is why I’ve failed to report this problem through your NOC.How can Meta replicate the failure?1: Look for random MNA cluster IPs from your clients. 2: Ping from 157.240.14.15 with a payload larger than 500 bytes (a packet is more likely to get corrupted on a faulty interface if the payload increases). 3: Ping many servers from point 1.You will see that once you find the affected upstream or downstream route combination, you will have 10-60% packet loss to the destination host.How to fix it? Isolate the port or discard faulty hardware.Why didn’t we see it before?Simply put, your monitoring tools and troubleshooting protocols don’t work for these problems. The protocol is to attach a HAR file that bases its performance on window scaling and TCP RTT; if both are good, even with data loss, there’s “no problem.” Especially because that HAR file is extracted using QUIC, and QUIC is particularly good at mitigating slowness caused by data loss (since packets are retransmitted without the TCP penalty). You know what uses TCP? WhatsApp Statuses, and those are slow.Can an MTR show where the problem is?Generally not, this is because:In any network route, there is a certain number of hops; for example, suppose there are 5 hops between host A and host B. To perform a traceroute, packets are sent with increasing TTL values (1, 2, 3, etc.). Each time a packet expires before reaching its destination, the transit hop reports a “TTL Time Exceeded” message, which is how the route is mapped. The problem is that these are basically point-to-point probes; it’s like pinging each hop individually. And when there’s a problem on an affected interface in an ECMP or bundle, those P2P connections won’t necessarily take the affected path. So they are unreliable; generally, you will see that the losses are produced by the final host even though the fault is in the middle. check metafixthis.com

Meta problem with URPF our bundle in Boca raton

Pi – A minimal terminal coding harness

Hi HN,A while ago I had a mildly depressing realization.Back in 2010, I had around $60k. Like a &quot;responsible&quot; person, I used it as a down payment on an apartment. Recently, out of curiosity, I calculated what would have happened if I had instead put that money into NVIDIA stock.I should probably add some context.For over 10 years I&#x27;ve worked as a developer on trading platforms and financial infrastructure. I made a rule for myself - never trade on the market.In 2015, when Bitcoin traded about 300 usd, my brother and I were talking about whether it was a bubble. He made a bold claim that one day it might reach $100k per coin. I remember thinking it sounded unrealistic - and even if it wasn&#x27;t, I wasn&#x27;t going to break my rule.That internal tension - building systems around markets while deliberately staying out of them is probably what made the &quot;what if?&quot; question harder to ignore years later.The result was uncomfortable. The opportunity cost came out to tens of millions of dollars.That thought stuck with me longer than it probably should have, so I decided to build a small experiment to make this kind of regret measurable:
<a href="https:&#x2F;&#x2F;shouldhavebought.com" rel="nofollow">https:&#x2F;&#x2F;shouldhavebought.com</a>At its core, the app does one basic thing:
you enter an asset, an amount, and two dates, and it gives you a plain numeric result - essentially a receipt for a missed opportunity.I intentionally designed the UI to feel raw and minimal, almost like a late-90s terminal. No charts, no images, no emotional cushioning - just a number staring back at you.What surprised me wasn&#x27;t the result, but how much modern web infrastructure it took to build something that looks so simple.Although the app is a single page with almost no UI elements, it still required:- Client-side reactivity for a responsive terminal-like experience (Alpine.js)- A traditional backend (Laravel) to validate inputs and aggregate historical market data- Normalizing time-series data across different assets and events (splits, gaps, missing days)- Dynamic OG image generation for social sharing (with color&#x2F;state reflecting gain vs loss)- A real-time feed showing recent calculations (&quot;Wall of Pain&quot;), implemented with WebSockets instead of a hosted service- Caching and performance tuning to keep the experience instant- Dealing with mobile font rendering and layout quirks, despite the &quot;simple&quot; UI- Cron and queueing for historical data updatesAll of that just to show a number.Because markets aren&#x27;t one-directional, I also added a second mode that I didn&#x27;t initially plan: &quot;Bullet Dodged&quot;.
If someone almost bought an asset right before a major crash, the terminal flips state and shows how much capital they preserved by doing nothing. In practice, this turned out to be just as emotionally charged as missed gains.Building this made me reflect on how deceptive &quot;simplicity&quot; on the web has become. As a manager I know says: &quot;Just add a button&quot;. But even recreating a deliberately primitive experience today requires understanding frontend reactivity, backend architecture, real-time transport, social metadata, deployment, and performance tradeoffs.I didn&#x27;t build this as a product so much as an experiment - part personal curiosity, part technical exploration.I&#x27;d be very interested to hear how others think about:Where they personally draw the line on stack complexity for small projects?Whether they would have gone fully static + edge functions for something like this?How much infrastructure is &quot;too much&quot; for a deliberately minimal interface?And, optionally, what your worst &quot;should have bought&quot; moment was?Happy to answer any technical questions or dig into specific implementation details if useful.

Show HN: Quantifying opportunity cost with a deliberately "simple" web app

Japanese Death Poems

I wanted to share our new speech to text model, and the library to use them effectively. We&#x27;re a small startup (six people, sub-$100k monthly GPU budget) so I&#x27;m proud of the work the team has done to create streaming STT models with lower word-error rates than OpenAI&#x27;s largest Whisper model. Admittedly Large v3 is a couple of years old, but we&#x27;re near the top the HF OpenASR leaderboard, even up against Nvidia&#x27;s Parakeet family. Anyway, I&#x27;d love to get feedback on the models and software, and hear about what people might build with it.

Show HN: Moonshine Open-Weights STT models – higher accuracy than WhisperLargev3

Cl-kawa: Scheme on Java on Common Lisp

Mercury 2: Fast reasoning LLM powered by diffusion

Ed Zitron loses his mind annotating an AI doomer macro memo

Mac mini will be made at a new facility in Houston

Hacking an old Kindle to display bus arrival times

Hey HN! We’re Arne and Raban, the founders of Emdash (<a href="https:&#x2F;&#x2F;github.com&#x2F;generalaction&#x2F;emdash" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;generalaction&#x2F;emdash</a>).Emdash is an open-source and provider-agnostic desktop app that lets you run multiple coding agents in parallel, each isolated in its own git worktree, either locally or over SSH on a remote machine. We call it an Agentic Development Environment (ADE).You can see a 1 minute demo here: <a href="https:&#x2F;&#x2F;youtu.be&#x2F;X31nK-zlzKo" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;X31nK-zlzKo</a>We are building Emdash for ourselves. While working on a cap-table management application (think Stripe Atlas + Pulley), we found our development workflow to be messy: lots of terminals, lots of branches, and too much time spent waiting on Codex.Emdash puts the terminal at the center and makes it easy to run multiple agents at once. Each agent runs as a task in its own git worktree. You can start one or a few agents on the same problem, test, and review.Emdash works over SSH so you can run agents where your code lives and keep the parallel workflow. You can assign tickets to agents, edit files manually, and review changes.We also spent time making task startup fast. Each task can be created in a worktree, and creating worktrees on demand was taking 5s+ in some cases. We now keep a small reserve of worktrees in the background and let a new task claim one instantly. That brought task start time down to ~500–1000ms depending on the provider. We also spawn the shell directly and avoid loading the shell environments on startup.We believe using the providers’ native CLIs is the right approach. It gives you the full capabilities of each agent, always. If a provider starts supporting plan mode, we don&#x27;t have to add that first.We support 21 coding agent CLIs today, including Claude Code, Codex, Gemini, Droid, Amp, Codebuff, and more. We auto-detect what you have installed and we’re provider-agnostic by design. If there’s a provider you want that we don’t support yet, we can add it. We believe that in the future, some agents will be better suited for task X and others for task Y. Codex, Claude Code, and Gemini all have fans. We want to be agnostic and enable individuals and teams to freely switch between them.Beyond orchestration, we try to pull most of the development loop into Emdash. You can review diffs, commit, open PRs, see CI&#x2F;CD checks, and merge directly from Emdash once checks pass. When starting a task, you can pass issues from Linear, GitHub, and Jira to an agent. We also support convenience variables and lifecycle scripts so it’s easy to allocate ports and test changes.Emdash is fully open-source and MIT-licensed.Download for macOS, Linux or Windows (as of yesterday !), or install via Homebrew: brew install --cask emdash.We’d love your feedback. How does your coding agent development setup look like, especially when working with multiple agents? We would want to learn more about it. Check out our repository here: <a href="https:&#x2F;&#x2F;github.com&#x2F;generalaction&#x2F;emdash" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;generalaction&#x2F;emdash</a>We’ll be around in the comments — thanks!

Show HN: Emdash – Open-source agentic development environment

I pitched a roller coaster to Disneyland at age 10 in 1978

Scheme-langserver digest incomplete Scheme code to serve real-world programming requirements, including goto-definition, auto-completion, type inference and such many LSP-defined language feature supports. And this project is based here(<a href="https:&#x2F;&#x2F;github.com&#x2F;ufo5260987423&#x2F;scheme-langserver" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;ufo5260987423&#x2F;scheme-langserver</a>).I built it because I was tired of Scheme&#x2F;Lisp&#x27;s raggy development environment, especially of the lack of IDE-like highly customized programing experience. Though DrRacket and many REPL-based counterparts have don&#x27;t much, following general cases aren&#x27;t reach same-level as in other modern languages:
(let* ([ready-for-reference 1]<pre><code> [call-reference (+ ready-for-)]))

</code></pre>
Apparently, the `ready-for-` behind `call-reference` should trigger an auto-complete option, in which has a candidate `ready-for-reference`. Besides, I also know both of them have the type of number, and their available scope is limited by `let*`&#x27;s outer brackets. I wish some IDE to provide such features and such small wishes gradually accumulated in past ten years, finally I wasn&#x27;t satisfied with all the ready-made products.If you want some further information, you may refer my github repository in which has a screen-record video showing how you code get help from this project and this project has detailed documentation so don&#x27;t hesitate and use it.Here&#x27;re some other things sharing to Hacker News readers:1. Why I don&#x27;t use DrRacket: LSP follows KISS(Keep It Simple, Stupid) principle and I don&#x27;t want to be involved with font things as I just read in its github issues.2. What&#x27;s the newest stage of scheme-langserve: It achieves kind of self-boost, in which stage I can continue develop it with its VScode plugin help. However, I directly used Chez Scheme&#x27;s tokenizer and this leaded to several un-caught exceptions whom I promise to be fixed in the future, but I&#x27;m occupied with developing new feature. If you feel something wrong with scheme-langserver, you may reboot vscode, generally this always work.3. Technology road map: I&#x27;m now developing a new macro expander so that the users can customize LSP behavior by coding their own macro and without altering this project. After this, I have a plan to improve efficiency and fix bugs.
4. Do I need any help: Yes. And I&#x27;d like to say, talking about scheme-langserver with me is also a kind of help.5. Long-term View: I suspect 2 or 3 years later I will lose concentration on this project but according some of my friends, I may integrate this project with other fantastic work.

Show HN: Scheme-langserver – Digest incomplete code with static analysis

Nearby Glasses

Sovereignty in a System Prompt

Steel Bank Common Lisp

Amazon accused of widespread scheme to inflate prices across the economy

Cell Service for the Fairly Paranoid

Corgi Labs (YC W23) Is Hiring

Anthropic Drops Flagship Safety Pledge

Hugging Face Skills

3D-Printed electric motor via multi-modal, multi-material extrusion

We installed a single turnstile to feel secure

Looks like it is happening

Aesthetics of single threading

Stripe valued at $159B, 2025 annual letter

Every MCP tool call dumps raw data into Claude Code&#x27;s 200K context window. A Playwright snapshot costs 56 KB, 20 GitHub issues cost 59 KB. After 30 minutes, 40% of your context is gone.I built an MCP server that sits between Claude Code and these outputs. It processes them in sandboxes and only returns summaries. 315 KB becomes 5.4 KB.It supports 10 language runtimes, SQLite FTS5 with BM25 ranking for search, and batch execution. Session time before slowdown goes from ~30 min to ~3 hours.MIT licensed, single command install:&#x2F;plugin marketplace add mksglu&#x2F;claude-context-mode&#x2F;plugin install context-mode@claude-context-modeBenchmarks and source: <a href="https:&#x2F;&#x2F;github.com&#x2F;mksglu&#x2F;claude-context-mode" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;mksglu&#x2F;claude-context-mode</a>Would love feedback from anyone hitting context limits in Claude Code.

Show HN: Context Mode – 315 KB of MCP output becomes 5.4 KB in Claude Code