DEV Community: Puneet Nanda

A URL Is Not a File

Puneet Nanda — Tue, 03 Nov 2026 15:01:48 +0000

A bookmark is a polite request. If you want the page later, save the HTTP responses while that server still sends them.

A fansite for a forgotten anime sat online, barely changed, from 2004 until the domain started serving gambling ads. The person who missed it works in web archiving. They still had no copy. Fondness never triggered a crawl.

Save the conversation, not a souvenir of it. A screenshot is a picture of the layout. A "Save as HTML" file is often the shell, with the images and the follow-up requests still living on a host you do not control. WARC writes down each request and each response, headers included. A WACZ bundles those records so a replay can answer from the file after the origin is gone, JavaScript included.

A public archive will not cover your bookmarks for you. It saves what it crawled. Open a link from a few years ago and you can get a 404 with nothing useful in the Wayback Machine. An old Angelfire site is still there as the bones. The hand-scanned photos are not. A forum went dark, and most of it had never been crawled. Ask a model to rebuild that and you get smooth paragraphs where the threads were. Training does not recreate a JPEG nobody fetched.

The pages that vanish on you are the ones with no fan club and no dump. A professor's course site, written as plain HTML, is the whole demo. wget -mkpnp while it still answers, and those notes are on your disk years later when you are prepping for an interview. Wait for the department to redesign, and you get a parking page.

If a menu only loads its data after a click, a capture that never clicked stored a hole with a nice title. You have to fetch the page the way you actually use it, while it still works.

Don't do this:

Count a bookmark as a copy.
Assume the Internet Archive already grabbed the URL you will miss.
Keep a screenshot and delete the assets it points at.
Notice the site is dead, then ask an LLM to invent the missing posts.
Leave the only WACZ on the only laptop in the house. Send a copy to someone else who wants the site.

If the bytes are not on a disk you control, you do not have the page. You have a rumor with a hyperlink.

If you love a website, back it up

Discussion on Hacker News

This post was generated automatically from public Hacker News data.

"Nobody Is Faster" Is Not a Date

Puneet Nanda — Tue, 03 Nov 2026 07:07:04 +0000

A speed promise is a number of days, or it is a slogan. Slogans do not show up late.

Ubuntu's security page says nobody provides fixes faster than Canonical. For CVE-2026-98432, a critical kernel bug, their own tracker still says Vulnerable on current LTS releases.

Debian's security tracker already lists fixed kernels for the same CVE. The slogan has no due date. The table does.

"Fast" cannot miss. "Within 7 days of the CVE page going up" can.

If you will not write the number, you do not have a patch policy. You have a typeface.

Watch the thing a package upload changes. That is the status line, and the kernel version in the security pocket.

The homepage does not rebuild when a fix ships. It also does not blush when the status sits on "work in progress."

The whole policy fits in an alert. Critical kernel CVEs are fixed in the image within N days of publication, or a person gets paged.

N is a number you would hate to miss. Seven and fourteen are both real choices.

"Timely" is a shrug.

CVE-2026-98432 has been on Ubuntu's tracker since 15 October 2026. On 3 November the page still marked the current LTS releases Vulnerable.

The fix is labeled work in progress. You cannot boot that label, and apt cannot install it.

Until the row names a package, the machine is the one from day one.

Debian is the control, not the point. Their security pocket lists fixed packages for this CVE.

The company whose site says nobody is faster had not flipped its own row. Diff the two pages and skip the subplot.

Skip these:

Reading "LTS" as a clock. A support window is not a latency.
Treating "work in progress" as good enough for this week.
Trusting a superlative with no due date. "Nobody is faster" cannot be late, which is how you know it is useless.
Letting the VPS default pick the distro, then calling that a review.
Waiting for the marketing page to correct the tracker. It is not on the release hook.

Put the CVE id next to the package version you expect. When N days pass and the row still says Vulnerable, that is the incident.

If they will not name the number of days, the CVE table is the contract.

WTF Ubuntu?

HN thread

This post was generated automatically from public Hacker News data.

131,072 Weights, and None of Them Were a Math Lesson

Puneet Nanda — Mon, 02 Nov 2026 22:49:43 +0000

A small edit can look like a new skill. Measure the failure you removed before you call the score learning.

That is the part worth stealing from a Hacker News thread about models that read and write neural network weights directly. Researchers at MIT CSAIL asked GPT-6 Astra to make Qwen3.5-0.8B better at math by editing weights. No gradients. No training loop. Astra traced a reasoning loop to one direction written by the MLPs in layers 15 and 19, then subtracted that direction from 64 output columns in each of those layers. The patch is 131,072 weights. On a model they describe as having 0.8 billion weights, that is 0.016%.

The scoreboard is easy to screenshot and easy to strip of context. MATH-500 went from 7.9% to 48.1%. GSM8K went from 13.8% to 67.1%. IFEval, which measures instruction following, went from 21.0% to 62.3%. Qwen's own model card already warns that this small model is prone to thinking loops. On the unedited model, 85 of the first 96 practice answers ran into the 32,768-token limit. After the edit that stuck, the share of MATH-500 answers hitting that limit fell from 93% to 33%.

The attempts that missed are the lesson. With 10 forward passes, MATH-500 only reached 12.3%, and 87.2% of answers still died at the cap. With 25 passes, 14.1% and 86.4%. The score did not climb while the model learned math. It sat still until the loop broke, and then it jumped. The loop is not special to math, which is why a non-math test moved too. A model that never lands the last line fails every exam that grades the last line.

The authors then ran the control that separates a blocker from a skill. Gemma 3 270M rarely loops. They report that only 8.5% of its answers reach its token limit, against 93% for that Qwen. Same style of direct weight edit. MATH-500 started at 6.8%, and no edited run moved it by more than about a point. The best figure in their table is 7.7%. On their account, Astra found ordinary wrong arithmetic and invalid algebra, with no single component to switch off. Fixing a loop lets the model finish answers it could already work out. Removing an obstacle that hid an ability does not install an ability the model lacked.

The same shape shows up in systems that have no weights at all.

Suppose an API's success rate climbs after you delete one retry bug: on timeout, call yourself until the gateway hangs up. Callers start getting a response. The handler did not get wiser. It stopped spending the whole deadline on a polite panic. Requests that were wrong for a real reason are still wrong. Success rate cannot tell those two stories apart. A math benchmark cannot either, once you crop the column that says the answer never finished.

Or take a function that returns early on a weird input, so the suite is a pile of timeouts. You delete the early return. The tests go green. The changelog says the score jumped. What jumped was termination. The missing branch is still missing. It is only visible now. That is worth shipping, and it is still not a new algorithm.

Do not publish the headline number and leave the blocker in a footnote you drop from the slide.

MATH-500 and "hit the token limit" are one measurement. Ten and twenty-five passes barely moved either one. Fifty passes moved both. If the score rises while the loop rate stays put, you might have taught something. If they move together, you unblocked a finish. Deleting while (true) is not a math curriculum. It is a favor to whoever pays for the electricity.

Before you trust a delta tomorrow, write the suspected blocker in one sentence, in the language of the system you have.

"It repeats until the sampler stops." "It retries until the gateway kills the request." "The test times out because we return before the hard case." Log that rate beside the score, on the same examples, before and after. Then find a control where the blocker is already rare. If the control sits still, you removed an obstacle. Put the remaining errors on a real plan: data, training, or code that implements the case you do not have yet.

Ship the unblocker. A model that can do the step, and then repeats until the token limit cuts it off, should have that habit removed. The patch was small because the habit was narrow. Do not send the next reader looking for a math lesson inside 131,072 weights that were only holding the door shut. The answers it could already work out were waiting behind that door.

Source: https://rikiyat.github.io/blog/weight-space-programming/

Hacker News: https://news.ycombinator.com/item?id=50341174

This post was generated automatically from public Hacker News data.

The Second Scrape Should Be Almost Free

Puneet Nanda — Mon, 02 Nov 2026 18:04:56 +0000

A one-shot script that classifies a forum archive feels done the moment the catalog shows up. It is not done. It has not met next Sunday.

The idea is less glamorous than a new video site, which is how you know it will still matter on Monday. An LLM label is a pure function of the text, the prompt, and the model. If none of those changed, you already bought the answer. Write it down. The second run should spend almost nothing.

This week's exhibit is a catalog of YouTube videos people on Hacker News have recommended since 2007. The interesting object is the pipeline, and it splits into two stages that should never share a function.

Stage one is a parser. Walk a comment, pull out a YouTube URL or video id, and store the hit next to the comment id. That step is deterministic. Run it every night. It will give you the same rows it gave you yesterday, which is the highest compliment a pipeline can receive.

Stage two is the judgment. A link is not a recommendation. One person is praising a conference talk. Another is pasting the same URL to complain about the codec. A third comment is spam with a video id glued to the end. You want those separated, and you probably want a topic so the catalog is browsable. That call is the whole budget.

On the Hacker News thread, the author reported about 504 million input tokens and 7.6 million output tokens for the project, more than 90 percent of them spent labeling comments. Building and deploying the app was on the order of a million tokens. Sit with that ratio before you schedule anything. The interface is a view over a table. The table is what you paid for.

Keep the table. One row per judgment:

the comment id
a hash of the comment body
a prompt version
the model name
the label
when you labeled it

The hash matters because comments get edited, and an edit is a new input. The prompt version is an integer you increment when the instructions change. A lookup key of comment id, content hash, prompt version, and model turns a rerun into a read. You are not asking the model whether it still agrees with itself.

Beside the table, store a watermark: the newest item id you have fully processed. Each run fetches only newer items, extracts links, and calls the model only when that key is missing. Then it moves the watermark forward. The first run walks the archive. Every later run is a delta. If the front page adds forty comments overnight, you pay for forty judgments, not for 2007.

The common failure is a script with an honest name like rebuild.py. It downloads the corpus and labels every row, on the theory that the provider's prompt cache will catch the repeat. It will not, not for long. Those caches expire. They miss when you change a single line of the system prompt. They also do not promise the same output twice, so a comment from 2009 can grow a new topic on Thursday and the catalog flickers for no editorial reason. Cached input does not make output tokens free. You have built a small business whose only product is paying a model to re-read "this talk is great."

There is a quieter version of the same bug. You change the prompt, forget to bump the version, and celebrate a perfect hit rate. You are serving last month's policy under this month's filename. Stale labels are fine when you chose them and can see the migration. They are a defect when the cache hid them.

Tomorrow, add the table before you add the schedule. At the end of every run, print two counts: comments seen, and comments sent to the model. After the first backfill those numbers should diverge, hard. If they stay equal, the watermark is a comment in the code, and you are still running the demo.

HackerTube, the source post

Hacker News discussion

This post was generated automatically from public Hacker News data.

A Brighter Flashlight Makes the Release Look Late

Puneet Nanda — Mon, 02 Nov 2026 18:00:25 +0000

A better bug finder does not mean the code got worse. It means you can finally see the bottle caps from 1987, and someone still has to decide which ones to dig up before lunch.

That is the lesson. Detection got cheap. Judgment did not. A release calendar that pretends those two speeds match will slip, or it will ship a fix that should never have been committed.

PostgreSQL major releases have been boring for a decade, in the good way: no earlier than mid-September, no later than mid-October. This year broke the pattern. Robert Haas wrote that version 19 will most likely wait until November, and might wait longer. Three large features came out between August 27 and September 15, deep in beta: UPDATE/DELETE FOR PORTION OF, SQL Property Graph Queries, and partition merge/split. Yanking a big feature right after the April feature freeze is ordinary. Yanking several of them at the end of summer is not.

The interesting part is where the extra work went. Haas compared April 8 through September 25. In 2025, master got 1,037 commits and the stable branch for the release then in progress got 724. In 2026 those numbers were 1,443 and 1,169. Commits that landed only on master declined slightly. Back-patched commits jumped by more than 60 percent. The previous stable branch did the same thing: 248 commits in that window last year, 433 this year, more than 74 percent. The committers did not suddenly get careless. A lot more people are pointing language models at a codebase whose history runs past thirty years, and filing what those models surface. Drafting a patch got easier. Reviewing one did not. The people allowed to commit still have the same number of hours.

Treat it as a queue, because it is one.

Findings per week are the arrival rate. Reviewed fixes that meet the project's own rules are the service rate. For a long time those rates were close enough that the train left on time. Then arrivals jumped, and service did not. A model can propose a patch in a closed loop: read the code, write a test, see if it fails. You can run that loop all night. The internet currently is. The loop that ships is open. It ends at a person who knows whether the patch is right, whether it belongs on every supported version, and whether the cure is worse than the bug. Haas is plain that model-written fixes are often wrong, or right in a way Postgres will not accept.

That is why the date moved. Hours that were supposed to answer "is this feature ready?" went to security issues and older bugs that had just become visible. Near a release, an unanswered question about a large feature has one responsible answer: take it out. Do that three times and you are off the old calendar. The delay is what quality looks like when inspection outruns repair. It is not proof that the code rotted in a single summer.

You have already seen the small version. Turn on a fuzzer, a sanitizer, or a stricter linter and the bug count spikes that week. Nobody rewrote the module overnight. You changed the sensor. If "bugs opened" is your quality score, you will scold the team for buying a better sensor, and someone will turn the sensor down until the chart behaves.

Don't do this: feed every new report to an agent and merge whatever comes back with a green test. Finding scales. Judgment does not. Plenty of defects in a system this old sit on extreme edges, and the tidy fix deletes a feature or spends a performance budget you do not have. A patch that compiles is not a patch you understand. In a database, the difference is someone's data.

Tomorrow, before you enable the new finder, write two numbers where the team will see them. How many findings a week a human can actually close. What gets dropped when the queue passes that. Drop scope. Keep the security work. Split the chart in two: bugs introduced after the cutoff, and bugs discovered after the cutoff. One series tells you if new code is getting worse. The other tells you the flashlight works. Keep only one series and the retro becomes an argument about a failure that never happened.

Point the finder at the oldest code your users still run. That is the buried layer. Budget the digging before you announce the count.

Source: Postgres 19 is late, and it's AI's fault

Discussion: Hacker News

This post was generated automatically from public Hacker News data.

Hacker News Has a Bookshelf. The Ranking Is the Hard Part

Puneet Nanda — Mon, 02 Nov 2026 17:53:28 +0000

The top story on Hacker News is a bookshelf made from the site's own comments. HackerBooks, posted by roansh, led the front page with 1,771 points and 289 comments. It applies the idea behind Andrej Karpathy's HackerTube to books: titles named on the site since 2007, each linked to the comment that named it. Karpathy replied "Love it!"

roansh says Claude Opus 5.5 wrote almost all of the pipeline and the site. Steering, a few decisions, and the domain were the human part. The layout brief was to feel like HackerTube, but for books. What is unusual is the artifact: a compiled index of a public archive, a CSV on the about page, and no account required.

What the index contains

The launch post says roughly 16,500 books were mentioned by at least two commenters. The about page, beside a dataset generated on November 2, 2026, lists 15,766 books, 281,363 mentions, 225,861 comments, and 57,773 commenters. The first number is the launch sketch. The second is the one that ships with the file.

The pipeline starts from the public Hacker News dump. Patterns pick out quoted titles, "by Author" phrases, store and Open Library links, and ISBNs. Those candidates are matched to Open Library for an id, authors, a year, a cover, and subjects, then searched across the whole corpus so an unlinked title still counts. A small model handles only ambiguous names. The page cites "Dune", "Influence", and "Range".

roansh said the live site is plain JavaScript and static JSON on Cloudflare. About 30 kilobytes of top books load first. The rest of the roughly 16,000 titles follow in the background. Covers are on R2. Python and DuckDB build the tables offline on a laptop, with no live crawl. A monthly refresh, the author said, might be enough. Rankings prefer distinct commenters to one person repeating a title.

Why the ranking is the hard part

The launch post warned that praise and complaints both count. A commenter then noted Mein Kampf showing as recommended by 651 people. The label on the site was changed to "mentioned by."

A second pass, described on the about page, asks Claude Sonnet 5.5 to mark each mention as recommend, neutral, critical, or not about the book. "Recommended by" counts distinct recommenders. Films, games, and other same-name works are dropped. On 400 mentions, Claude Opus 5.5 agreed 85 percent of the time. Keyword rules, sentiment scores, and a TF-IDF classifier did worse. The page says noise remains.

The thread showed that noise. Vanity Fair the novel was inflated by the magazine, and roansh said it would count only alongside Thackeray. A dragon-book nickname hit the wrong record until the link was fixed. Readers also reported bad subject shelves, a publication decade that was far off, and sarcasm scored as praise. Why's (Poignant) Guide to Ruby was missing from Open Library and had to be added by hand. The Invention of Morel, mentioned by about three people, still drops out of the matcher.

A commenter totaled mentions by year and saw a peak in 2022, then a fall. Others said the series ignores how many people were posting, and that newer readers may mention fewer books. roansh asked if Hacker News traffic is down. The curve is about this archive, not about reading in general.

Who should care

Anyone using the chart as a reading list should open the comment. The thread itself was an argument about fiction, audiobooks, and how weak "most mentioned" is as a verdict. The link back to the sentence is the useful object. The sort order is only a way in.

Anyone extracting entities from forums should study the misses. Open metadata is incomplete, short titles collide, and a loose label will treat a denunciation as a pick. Commenters were also plain that covers and dates from Open Library are often wrong. Bookshop and Amazon links added during the thread are affiliate links, which the author disclosed.

Anyone who has lost an older HN book site to a 404 should take the CSV. Commenters cited earlier versions, including one from 2021, and a builder whose revival never shipped. The about page says browsing is untracked and that "For You" lives in localStorage on your machine. An email address is stored only if you ask for updates.

What is still open is whether the laptop job becomes a schedule, whether that 85 percent check survives sarcasm and name collisions, and whether the file is used once the points stop. Readers had already posted sibling indexes for products and for Wikipedia. They last if somebody keeps the table.

Source: HackerBooks. Discussion: Hacker News.

This post was generated automatically from public Hacker News data.