frontpage.
newsnewestaskshowjobs

Made with ♥ by @iamnishanth

Open Source @Github

fp.

Flash-Moe: Running a 397B Parameter Model on a Mac with 48GB RAM

https://github.com/danveloper/flash-moe
97•mft_•2h ago•32 comments

Bored of eating your own dogfood? Try smelling your own farts

https://shkspr.mobi/blog/2026/03/bored-of-eating-your-own-dogfood-try-smelling-your-own-farts/
24•ColinWright•26m ago•2 comments

Hormuz Minesweeper – Are you tired of winning?

https://hormuz.pythonic.ninja/
391•PythonicNinja•4h ago•217 comments

More common mistakes to avoid when creating system architecture diagrams

https://www.ilograph.com/blog/posts/more-common-diagram-mistakes/
19•billyp-rva•1h ago•5 comments

25 Years of Eggs

https://www.john-rush.com/posts/eggs-25-years-20260219.html
99•avyfain•3d ago•35 comments

Node.js worker threads are problematic, but they work great for us

https://www.inngest.com/blog/node-worker-threads
17•goodoldneon•3d ago•3 comments

My first patch to the Linux kernel

https://pooladkhay.com/posts/first-kernel-patch/
147•pooladkhay•2d ago•24 comments

A Case Against Currying

https://emi-h.com/articles/a-case-against-currying.html
3•emih•35m ago•0 comments

Convincing Is Not Persuading

https://blog.alaindichiappari.dev/p/convincing-is-not-persuading
4•alainrk•38m ago•0 comments

Project Nomad – Knowledge That Never Goes Offline

https://www.projectnomad.us
8•jensgk•1h ago•1 comments

Tinybox – A powerful computer for deep learning

https://tinygrad.org/#tinybox
528•albelfio•17h ago•298 comments

Brute-Forcing My Algorithmic Ignorance with an LLM in 7 Days

http://blog.dominikrudnik.pl/my-google-recruitment-journey-part-1
6•qikcik•1h ago•0 comments

The three pillars of JavaScript bloat

https://43081j.com/2026/03/three-pillars-of-javascript-bloat
375•onlyspaceghost•11h ago•216 comments

A Review of Dice That Came with the White Castle

https://boardgamegeek.com/thread/3533812/a-review-of-dice-that-came-with-the-white-castle
12•doener•3d ago•2 comments

Some things just take time

https://lucumr.pocoo.org/2026/3/20/some-things-just-take-time/
757•vaylian•22h ago•240 comments

Professional video editing, right in the browser with WebGPU and WASM

https://tooscut.app/
306•mohebifar•16h ago•109 comments

Chest Fridge (2009)

https://mtbest.net/chest-fridge/
137•wolfi1•12h ago•76 comments

$ teebot.dev – from terminal to tee in 6 seconds

https://teebot.dev
5•foxpress•1h ago•3 comments

Windows native app development is a mess

https://domenic.me/windows-native-dev/
52•domenicd•3h ago•49 comments

How We Synchronized Editing for Rec Room's Multiplayer Scripting System

https://www.tyleo.com/blog/how-we-synchronized-editing-for-rec-rooms-multiplayer-scripting-system
4•tyleo•1h ago•4 comments

'Miracle': Europe reconnects with lost spacecraft

https://phys.org/news/2026-03-miracle-europe-reconnects-lost-spacecraft.html
56•vrganj•3h ago•22 comments

Floci – A free, open-source local AWS emulator

https://github.com/hectorvent/floci
229•shaicoleman•15h ago•66 comments

HopTab–free,open source macOS app switcher and tiler that replaces Cmd+Tab

https://www.royalbhati.com/hoptab
59•robhati•7h ago•18 comments

Can Programming Be Liberated from the von Neumann Style? (1977) [pdf]

https://worrydream.com/refs/Backus_1978_-_Can_Programming_Be_Liberated_from_the_von_Neumann_Style...
5•tosh•1h ago•1 comments

Turns out your coffee addiction may be doing your brain a favor

https://www.theregister.com/2026/03/21/turns_out_your_coffee_addiction/
7•Bender•46m ago•1 comments

Vatican Rebukes Peter Thiel's Antichrist Lectures in Rome

https://www.thenerdreich.com/peter-thiels-antichrist-circus-smacked-down-in-rome/
54•vrganj•4h ago•40 comments

Electronics for Kids, 2nd Edition

https://nostarch.com/electronics-for-kids-2e
219•0x54MUR41•3d ago•47 comments

Boomloom: Think with your hands

https://www.theboomloom.com
145•rasengan0•1d ago•15 comments

Bayesian statistics for confused data scientists

https://nchagnet.pages.dev/blog/bayesian-statistics-for-confused-data-scientists/
150•speckx•3d ago•41 comments

Cross-Model Void Convergence: GPT-5.2 and Claude Opus 4.6 Deterministic Silence

https://zenodo.org/records/18976656
42•rayanpal_•6h ago•21 comments
Open in hackernews

Infinite Tool Use

https://snimu.github.io/2025/05/23/infinite-tool-use.html
83•tosh•10mo ago

Comments

anko•10mo ago
I have been thinking along these lines myself. Most of the time, if we need to calculate things, we'd use a calculator or some code. We wouldn't do it in our head, unless it's rough or small enough. But that's what we ask LLMs to do!

I believe we juggle 7 (plus or minus 2) things in our short term memory. Maybe short term memory could be a tool!

We also don't have the knowledge of the entire internet in our heads, but meanwhile we can still be more effective at strategy/reasoning/planning. Maybe a much smaller model could be used if the only thing it had to do is use tools and have a basic grasp on a language.

dijit•10mo ago
I was once told that we can only hold 7 things in our heads at once, especially smart people might manage 9; this was by a psychologist that I respect- whether its true or not I am not certain. He was using it as an argument to either condense the array of things I was thinking about into smaller decisions, or to make decisions and move on instead of letting them rot my brain.

It was good advice for me.

blixt•10mo ago
Let’s not forget that every round trip with the LLM costs latency (and extra input tokens). We now have parallel tool calls which sometimes works in some models[1]. But it’s great because now a model can say “write these 3 files then read these 2 files” before the time-to-first token latency is incurred once more (not to mention input token cost).

I think LLMs will indirectly move towards being fuzzy VMs that output tokens much like VM instructions so they can prepare multiple conditional branches of tool calling, load/unload useful subprograms, etc. It might not be expressed exactly like that, but I think given how LLMs today are very poor at reusing things in their context window, we will naturally add features that take us in this direction. Also see frameworks like CodeAct[2] etc.

[1] This can be converted to a single tool call with many arguments instead, which you’ll see providers do in their internal tools, but it’s just messier.

[2] https://machinelearning.apple.com/research/codeact

brador•10mo ago
Your only useful purpose is to assign the goal. Everything else is an uppity human getting in the way of a more efficient (and more creative) production system.
rahimnathwani•10mo ago
I'm wondering how we might apply this to the task of writing a novel.

There's an open source tool being developed that is sort of along these lines: https://github.com/raestrada/storycraftr

But:

- it expects the user to be the orchestrator, rather than running fully unattended in a loop, and

- it expects the LLM to output a whole chapter at a time, rather than doing surgical edits: https://github.com/raestrada/storycraftr/blob/b0d80204c93ff1...

(It does use a vector store to help the model get context from the rest of the book, so it doesn't assume everything is in context.)

ksilobman•10mo ago
> Give it access to a full text-editor that is controllable through special text-commands, and see many benefits

I’d like to apply what is being suggested in this post, but it doesn’t make sense to me to have to give an LLM access to a text editor just to write a novel. Isn’t there a better way?

dazzaji•10mo ago
I’m still stuck on the first sentence "An LLM should never output anything but tool calls and their arguments” because it just doesn’t make sense to me.

Tool calling is great, but LLMs are - and should be used as - more than just tool callers. I mean, some tools will have to be other LLMs doing what they’re good at, like writing a novel, summarizing, brainstorming ideas, or explaining complex topics. Tools are useful, but the stuff LLMs actually do is also useful. The basic premise that LLMs should never output anything beyond tools and arguments is leaving most of the value of LLMs on the table.

bsenftner•10mo ago
I think the blog simply does not explain well. Consider the example of a text editor, the "tool calls" are text fragments generated by the LLM then embedded into text editor tool calls that place the generated text fragment into the text editor, performing cuts, pastes, and so on.

FWIW, I've done this and it works incredibly well. It's essentially integrating the LLM into the text editor, and requests of the LLM are more like requests of the text editor directly. The mental model I use is the editor has become an AI Agent itself. I've also done with with spreadsheets, web page editors, various tools in project management software. It's an incredible perspective that works.

dazzaji•10mo ago
Got it, thanks for clarifying! So if I’m understanding you right, you’re saying that all the generative stuff the LLM does—like creating text—basically becomes part of the ‘arguments’ the original post talks about, and then that gets paired with a tool call (like inserting into a text editor, doing edits, etc.). I was focused on the tool call not the argument content aspect of the post.

And it sounds like you’ve had a lot of success with this approach in an impressive variety of application types. May I ask what tooling you usually use for this (eg custom python for each hack? MCP? some agent framework like LangGraph/ADK/etc, other?)

bsenftner•10mo ago
I noticed fairly early that the foundation LLMs have the source code to most FOSS, as well as the developer conversations, the user discussions trying to understand how to use that software, and the documentation too. The foundational models have a good amount of training data of each popular FOSS app, and by examining the code and the developer comments, and then adopting their language style, the LLM practically takes on the persona of the developer. So I spent some time understanding the internal communications of each app, and my 'tool calls' are structured JSON of the internal structures these applications use, and my own code receives these structured outputs and I just replace in the application's running memory. Not quite so blind as I describe, some of the insertion of these data structures is complicated.

In the end, each app is both what it was before, as well as can be driven by prompts. I've also specialized each to have 4 agents that are as I describe, but they each have a different representation of the app's internal data; for example, a word processor has the "content, the document" in HTML/CSS as well as raw text. When one wants to manipulate the text, requests use the HTML/CSS representation, and selections go through a slightly separate logic than a request to be applied to the entire document. When one wants to critically analyze the text, it is ASCII text, no need for the HTML/CSS at all. When one wants to use the document as a knowledge base, outside the editor, that's yet another variant that uses the editor to output a RAG ready representation.

dazzaji•10mo ago
That system would make a tidy startup, especially if tightly integrated with an open source office suite behind the scenes (LibreOffice, OpenOffice, etc) and a generative AI native UX.
dazzaji•9mo ago
* I'd call it "VibeOffice".
ayolisup•10mo ago
A naive approach could be to create an outline, then have an LLM randomly sample a section, supply the surrounding context, rewrite that part, then repeat, ideally alongside human writing. Some sort of continuous revision cycle.
yencabulator•10mo ago
The underlying problem might get solved differently with diffusion.

https://news.ycombinator.com/item?id=44057820

PeterStuer•10mo ago
In theory not being 'locked in' on the early generation track is a potential advantage of diffusion LLM's. In practice it remains to be seen wether they can truly outperform the current standard LLM with heurstics.