MurphyA/hacker-news huggingface dataset:
by dnhkng | 2026-03-10 16:18:17+00:00
Yes, I've tried duplicating layers, but its useful.

I think this hasn't been tried before because it's totally unintuitive that feeding the output from later layers into previous ones would actually do anything. And in fact, it usually is detrimental. I guess it takes really bored hobbyists with too much compute to check this stuff.

This works with MoE, and yes, I would be interested in looking into this in more detail. But my wife might disagree with this time sink...
by caminante | 2026-03-10 16:18:22+00:00
Ha! You're right. That's not your quote.

Though, you did say formula "isn't cheap" in a comment questioning the the ROI. I'm lost because that would imply you had run the numbers to call it expensive.

I agree that every family's different. I'm overly touchy on the phrasing to a fault. You get it. My point is that people seem to lean into this or over worry about breastfeeding at all costs.
by sidkshatriya | 2026-03-10 16:18:34+00:00
Yes, within Linux there is diversity -- I was not talking about that. The server space in 2026 is dominated by Linux.

Solaris ? Gone* WindowsNT ? Niche. HP-UX ? Gone* AIX ? Gone* macOS ? Not in server. FreeBSD ? Niche (smaller than WindowsNT though).

In another world there would be at least two open source server os-es battling it out (like in hardware where we have aarch64 vs x64 and so on).

(*) "Gone" means probably a rounding error by now.
by saila | 2026-03-10 16:18:35+00:00
Good tools can improve your workflow for sure, but it's easy enough to keep a clean history with a handful of git commands. There are two main reasons people don't do so: 1. they don't know the commands yet or 2. they just don't care (and are in an environment where there's no incentive to care).

The kind of person who would try a tool like Magit and use it to discover git would have found a different route if Magit didn't exist. The type of person who doesn't care isn't going to learn something just because a tool is available.
by MDGeist | 2026-03-10 16:18:39+00:00
A former colleague of mine recently took a role that has largely turned out to be "greybeard that reviews the AI slop of the junior engineers". In theory it sounds workable, but the volume of slop makes thoughtful review impossible. Seems like most orgs will just put pressure on the slop generators to do more and put pressure on the approvers and then scape goat the slop approvers if necessary?
Show HN: What was the world listening to? Music charts, 20 countries (1940–2025)
by matteocantiello | 2026-03-10 16:18:40+00:00
I built this because I wanted to know what people in Japan were listening to the year I was born. That question spiraled: how does a hit in Rome compare to what was charting in Lagos the same year? How did sonic flavors propagate as streaming made musical influence travel faster than ever?
88mph is a playable map of music history: 230 charts across 20 countries, spanning 8 decades (1940–2025). Every song is playable via YouTube or Spotify. It's open source and I'd love help expanding it — there's a link to contribute charts for new countries and years. The goal is to crowdsource a complete sonic atlas of the world.
by ardeaver | 2026-03-10 16:18:42+00:00
When I was really early in my career, a mentor told me that code review is not about catching bugs but spreading context (i.e. increasing bus factor.) Catching bugs is a side effect, but unless you have a lot of people review each pull request, it's basically just gambling.

The more expensive and less sexy option is to actually make testing easier (both programmatically and manually), write more tests and more levels of tests, and spend time reducing code complexity. The problem, I think, is people don't get promoted for preventing issues.
by bloppe | 2026-03-10 16:18:55+00:00
> live in UTC

Technically, nobody lives in "UTC". You might say people live in UTC+0, which is a standard time zone around the prime meridian. UTC refers to the system of standard time zones, not a single time zone, but in common speech "UTC" is often understood to mean UTC+0.

Let's say you live in California. During the winter, you observe PST ("standard time"), which is UTC-8. During the summer, you probably observe PDT ("daylight time"), which is UTC-7. Switching between the two is sort of outside the scope of the UTC system. It happens locally and is subject to local social and political preferences. Digital clocks mostly just keep track of standard time and possibly adjust their output if presenting a human-readable timestamp string.

Leap seconds are very much inside the scope of UTC. A leap second occurs globally for every standard time zone at the exact same global instant. It's determined by an objective criterion based on UT1.
by devonkelley | 2026-03-10 16:19:28+00:00
This is the part nobody wants to talk about in the "just use the cheap model" discourse. The sticker price of the model is not the cost. The cost is the sticker price plus the human intervention rate times engineer salary. When your dashboard goes 50/50, you just doubled your effective cost because someone has to go figure out which half is broken. The models that "cost 10x more" often cost less in production because they don't generate rework.
by torginus | 2026-03-10 16:19:43+00:00
It can certainly be true for several reasons. Even in domains I'm familiar with, often making a change is costly in terms of coding effort.

For example just recently I updated a component in one of our modules. The work was fairly rote (in this project we are not allowed to use LLMs). While it was absolutely necessary to do the update here, it was beneficial to do it everywhere else. I didn't do it in other places because I couldn't justify spending the effort.

There are two sides to this - with LLMs, housekeeping becomes easy and effortless, but you often err on the side of verbosity because it costs nothing to write.

But much less thought goes into every line of code, and I often am kinda amazed that how compact and rudimentary the (hand-written) logic is behind some of our stuff that I thought would be some sort of magnum opus.

When in fact the opposite should be the case - every piece of functionality you don't need right now, will be trivial to generate in the future, so the principle of YAGNI applies even more.
by 9rx | 2026-03-10 16:19:48+00:00
> You're a human talking to other humans.

Okay. Let's put that to the test. Describe my human features. What do I look like, sound like?

> and my impression is that there's a sizable group of people who would have been happier if one of the proposals had been merged.

Fair enough. What do they say to the specific criticism that brought rejection?

> Sure, if you think that the people who make the language are infallibly able to both know and care about what's good for 100% of Go programmers

They satisfy 100% of Go programmers, but not all programmers. Those who aren't satisfied are already using another language or have forked Go to make it what they actually need. Even Google uses their own fork, funnily enough. If something doesn't work for you, you can't sensibly continue to use it.
by harperlabs | 2026-03-10 16:19:51+00:00
The multi-turn fragmentation is the one that trips up most testing frameworks -- ours included, initially. We saw it slip through in 8/50 test cases because we were generating single-turn injection attempts. The adversarial instructions didn't get semantically assembled until execution.

For the encoding vectors: we caught unicode homoglyphs by normalizing all inputs to NFKC before processing. Base64 and ROT13 still require intent modeling at the LLM layer, not sanitization. A proxy that doesn't decode 'this is base64' will pass it straight through.

The gap you're describing between 'we have an injection firewall' and 'we've tested adversarial encoding' is exactly where production failures hide. Would genuinely like to see the PromptGuard methodology when it goes out.
by mrothroc | 2026-03-10 16:20:02+00:00
The disposition problem you describe maps to something I keep running into. I've been running fully autonomous software development agents in my own harness and there's real tension between "check everything" and "agent churns forever".

It'a a liveness constraint: more checks means less of the agent output can pass. Even if the probabilistic mass of the output centers around "correct", you can still over-check and the pipeline shuts down.

The thing I noticed: the errors have a pattern and you can categorize them. If you break up the artifact delivery into stages, you can add gates in between to catch specific classes of errors. You keep throughput while improving quality. In the end, instead of LLMs with "personas", I structured my pipeline around "artifact you create".

I wrote up the data and reasoning framework here: https://michael.roth.rocks/research/trust-topology/
by imiric | 2026-03-10 16:20:02+00:00
Peculiarly, having used Emacs for a decade as my main editor, and Git for much more than that, I never could get used to Magit.

Maybe it's due to muscle memory from my CLI Git setup (nothing special, just some aliases, scmpuff, delta, etc.), or Magit forcing you into its own quirky UI, but it never clicked for me. For 99% of things I use Git for, I don't have any issues with my workflow, nor wish to improve it. For the other (very) rare occasions, I can always ask an LLM to help me figure out the right command.

This is also why I don't see any value in Jujutsu either, or any of the GUI/TUI wrappers. The Git CLI porcelain with some minor customizations just hasn't been a problem I need solving.
by hkonte | 2026-03-10 16:20:08+00:00
Validation is underrated. The same need for structure shows up on the prompt side too.

When your system prompt is one big paragraph, you can't easily tell which section causes unexpected output. Typed blocks (role, constraints, output format) give you the same verifiable surface that MCP gives you on the tool side. You can isolate and fix one block without touching the rest.

I built flompt (https://flompt.dev) for exactly this, a canvas that decomposes prompts into 12 typed blocks and compiles to Claude-optimized XML. Same idea: structure first, then composition. Open-source: github.com/Nyrok/flompt

A star on github.com/Nyrok/flompt is the best way to support it. Solo project, every star helps.
by ToddWBurgess | 2026-03-10 16:20:08+00:00
sysop breaking in for chat:

I remember getting a modem for Christmas 1990 (2400 baud modem) and logging into BBSs and my world would never be the same. I was a hardcore BBS user from 1990-1994.

In 1994, I got my first Unix account with Internet access when I started University. Once I saw the Internet there was no going back (even if it was only the 1994 edition) and I gave up on using BBSs ever again. I suspect most people have a similar story to mine.
by rosasalberto | 2026-03-10 16:20:51+00:00
There is many direct competitors in the space, the main ones are Persona, Jumio, Incode, Sumsub, and even orchestrators like Alloy.

In general I believe we just built a better product:

- Fastest verification on the market (inference time < 2s, well optimized infra, we do real time checks (for example when you do the front scan of the ID, we do the checks real-time, instead of waiting for the user to do the back, like persona does, and takes > 30 s, ours is less < 2 s).

- Optimized onboarding rate worldwide, global coverage, any country, low connectivity and every device accepted, and optimized (different models loading in the client depending on the speed ..etc, and many more tricks)

- Fraud detection (we analize > 200 signals, to detect fraud in real time, from IP analysis, device fingerprinting, replay attacks, deepfakes ...) we got experts on that, and we act quickly if we see new attack vectors appear.

- Developer experience (self-service, pay per usage, API first). You can start doing verifications without needed to use the UI (everything programatic), and integrate in few minutes.

- Flexible, you can create any identity flow with your own rules. You can enable features with just 1 click, no need to reintegrate.

- Pricing model (pay per usage, no monthly minimums, no enterprise gated, and low prices)
by nicbou | 2026-03-10 16:21:00+00:00
Invisible Women

If you liked Freakonomics, you will like this. It's not a rant, just one example after another of how we fail to account for half of the population.

I just finished The God of Small Things. The writing is phenomenal, but it was not quite my kind of book, so it took me a bit of effort to finish.
by notpachet | 2026-03-10 16:21:02+00:00
> no one is going to care about anyone’s bespoke manual keyboard entry of code if it takes 10 times as long to produce the same functionality with imperceptibly less error.

No one is going to care about anyone’s painstaking avoidance of chlorofluorocarbons if it takes ten times as long to style your hair with imperceptibly less ozone hole damage.
by rob_c | 2026-03-10 16:21:16+00:00
very awesome writeup, glad to see someone with access to hw actually playing with this.

Hopefully the cost per GPU will kick-it soon and we'll see people properly play, but frankly the "middle section" layers 2(ish) to (n-1)(ish) of a model can be shuffled up/down and left/right and still perform well.

The fun one will be an LLM router for LLM layers to apply the best reasoning to the best input so far, but frankly that would need the years and years of training that the author hints at.

The one that's still out of grasps is still how to combine/manipulate per-layer k,v caches into a globally coherent state.
i.e. if layers can be moved up/down why can't the cached k,v be swapped/combined with different projections?
global k,v caches work, but they have to be _huge_ in order to prevent model collapse even on something as simple as owt.
by orthogonal_cube | 2026-03-10 16:21:41+00:00
> Isn't this what parenthesizes are meant for?

Parentheses add emphasis to a sentence or statement. Normally the use of it allows the sentence to be complete with or without it.

Em dashes may also add or increase emphasis but are normally treated as an aside. Think of it as a comment by the author to inject themselves, sometimes in ways which do not form a complete sentence.

For example: When you read this sentence (in your mind) it should feel complete and correct. Perhaps you read in your own voice — something I don’t normally do — or without one at all.

> I don't understand what the issue even is here, and the RFC also doesn't clearly outline it.

The issue is written there but may not make sense unless you know someone who stylistically writes with high-than-average em dash usage. I, for example, get inquiries and comments at work from employees who ask what LLM model I used for “generating these reports” because of the presence of em dashes. They do not believe me when I say not a single word was written by LLMs because, “there’s an em dash. Only LLMs use em dashes!” This is categorically untrue and erodes the authenticity of work from people because of the correlation.

Their aim is to implement a new Unicode character which programs like text editors could inject when a person types an em dash. It attributes to a human being behind the document, typing characters out individually. Actions like copy-pasting text in bulk wouldn’t replace em dashes since it can’t attribute a human as writing it out.
by hard24 | 2026-03-10 16:22:27+00:00
My prediction is a concorde-like incident is going to shatter trust and make people re-think their expectations of the capabilities of LLMs and their abilities of the present.

Essentially something big has to happen that affects the revenue/trust of a large provider of goods, stemming from LLM-use.

They wont go away entirely. But this idea that they can displace engineers at a high-rate will.
by kworks | 2026-03-10 16:23:00+00:00
I initially came to the same conclusion. Though I lifted in accord with decent training principles regarding reps and sets, I didn't track for years. As I entered middle age, I started keeping a training log (just one big org file in emacs), mostly out of curiousity. As I entered my 50s, I experienced what Haruki Murakami references in "What I Talk About When I Talk About Running" --- Fat is easy to gain and hard to lose. Muscle is hard to gain and easy to lose.
Now I track a couple of critical metrics and it's working great. I weigh first thing every day, track all kcals (even if I overeat), plan and track workouts. I write my own plans pulled from principles in these books (don't work for the company, just a satisfied customer) https://muscleandstrengthpyramids.com/
I don't use the vast majority of the info in those books as I'm just a hobbyist who wants to be healthy and strong.
The biggest shift came from learning I was doing waaay too much training volume at the gym while trying to lose fat too quickly; a fine recipe for injury. Now, when I'm in a fat loss phase, I try to lose it as slowly as possible while still making progress. Strength training and fat loss is a very long very slow marathon, not a sprint.
Perhaps paradoxically, the awareness that's come from tracking has helped me relax. No need to major in the minors; pretty good is pretty good.
The tools I use are a scale, loseit, and org-mode.
by washadjeffmad | 2026-03-10 16:23:14+00:00
Age of account was sufficient for Google and third-party services for verification until recently. My gmail account is almost 22 years old, in continuous use. I have a credit card on file with Google Pay. Why would I need to submit a photo to engage with a private service, outside of volunteering to help train a surveillance apparatus?

Is there any forum short of a senate subcommittee that the public can ask companies these questions? The silence is deafening.
by system7rocks | 2026-03-10 16:23:33+00:00
This is why I come to this site. Some of the tech stuff goes over my head and limited skills, but this article was insightful and still so relevant. It probably applies to non-profit organizations that tend to falter after their visionary (aka psychopath) leader retires.

And it likely applies to a ton of churches out there, especially megachurches, where you walk in to the lobby and see leadership books by their star CEO aka pastor about leadership or life lessons or whatever. But those megachurches churn through employees until they find just enough psychopaths (aka executive pastors) willing to be assholes for God, plenty of clueless who are happy to serve as that middle management, and then those who are okay with being loyal and doing just enough week to week for a paycheck.

I've seen it all too often.

Check out the podcast Bodies Behind the Bus if you want a glimpse about what happens to those who actually call some of those megachurches to live into what they say - like actually caring for their neighbors.
by hananova | 2026-03-10 16:23:44+00:00
My manager can try. I’ll say no, and he’ll be welcome to start the slow process of laying me off, which will end in my employer having to pay me 10 months worth of wages. By the time I’ll be faced with having to find a new job, I’ll be retiring anyway. Using LLMs is not in my job description, and I will not do it.
by numpad0 | 2026-03-10 16:24:18+00:00
There are definitely >1m artists worldwide, some popular some less so, and $1M * 1m =1T, not 0.1% * 200T =200B.

Hard cap of 200B divided by 1M equals 200k, and that would be sure more reasonable, but we aren't hearing artists responding favorably to hypotheticals in that range, so I'm skeptical that "ain't nobody gonna turn that down".
by bdangubic | 2026-03-10 16:24:22+00:00
Obviously I can speak only from my personal experience but just me I have 5 examples of companies that were “no AI, IP and all that” that are now full-on “every developer must use CC, Cursor…”

How many conpanes today don’t have “AI strategy” and are fearing will be left behind etc? In my small circle we went from “most are not using AI” to “none are not using AI” in somewhat short period of time
by adev_ | 2026-03-10 16:24:30+00:00
Then we disagree.

> (and btw it's not just time that matters here)

My remark is still valid. Even considering memory space and cognitive complexity.

> even function calls are not always zero-cost. For multiple reasons, some of which differ across compilers more than others

Divergence about the support of inlining in compiler implementation have nothing to do with the debate here. Some idiosyncrasy about C++ argument passing and lifetime might causes a cost in some specific scenario, still that is specific to C++.

It still does invalid the concept of zero runtime cost for abstraction.

As much as people like to dismiss it, Stepanov was right all along.

> Nobody is concluding you shouldn't write functions either.

Then, you will be surprised to learn that some 'devs' actually recommend exactly this and write guideline that minimize the number of function written. They tend to be from the same crowd that the one was describing before.
by SlinkyOnStairs | 2026-03-10 16:24:30+00:00
Setting aside "make an issue first" because those too are flooded with LLMs.

> you are very unlikely to get a nontrivial patch or package into Debian unless you have some kind of interaction or rapport with a package maintainer

I did mean the "trivial" patches as well, as often it's a lot of these small little fixes to single issues that improve software quality overall.

But yes, it's true that it's not uncommon for projects to refuse outside PRs.

This already causes massive amounts of friction and contributes (heh) heavily to what makes Open Source such a pain in the ass to use.

Conversely, many popular "good" open source libraries rely extensively on this inflow of small contributions to become comprehensively good.

And so it's a tradeoff. Forcing all open source into refusing drive-by PRs will have costs. What makes sense for major security-sensitive projects with large resources doesn't make sense for others.

It's not that we won't have open source at all. It's that it'll just be worse and encourage further fragmentation. e.g. One doesn't build a good .ZIP library by carefully reading the specification, you get it by collecting a million little examples of weird zip files in the wild breaking your code.
by shagie | 2026-03-10 16:24:36+00:00
Ramadan really moves around the calendar. From what I understand, summertime Ramadan can be quite challenging to fast from sunrise to sunset. https://www.bibalex.org/SCIplanet/en/Article/Details.aspx?id...

That's part of the reason that Morocco does a time shift during Ramadan - moving sunrise an hour later in the day so that there is more time before dawn to have breakfast. It's daylight savings but for the purpose of more pre-dawn time than afternoon-sun time.

https://www.moroccoworldnews.com/2026/02/278108/morocco-to-r...

> Rabat – The Ministry of Digital Transition has announced that Morocco will suspend daylight saving time and return to GMT on Sunday, February 15 at 3 a.m for Ramadan 2026.

> Astronomical calculations expect Ramadan to begin on February 19 in Morocco. The Ministry of Islamic Affairs will confirm the official starting date after the sighting of the crescent moon.

> Morocco suspends daylight saving time exclusively for the holy month of Ramadan, as it affects the fasting time.

> The ministry emphasized that 60 minutes will be added to the official time at 2 a.m. on Sunday, March 22, following Ramadan.

> ...

> The North African country decided to adopt the daylight saving measure in 2008 during the summer season. The decision’s goal is to increase competitiveness of the national economy through reducing energy consumption and also the time difference between the country and its regional and international trading partners.

> Under the measure, Morocco switched the clock every summer to DST, GMT+1, and returned to the old standard time, GMT, for a period when Ramadan fell in the summer.

> In October 2018, however, the Moroccan government adopted Draft Decree 2.18.855, adding 60 minutes to the standard time in the country year-round.

> The decision stirred controversy and frustration, with Moroccans protesting the move. But it has since become a normal part of Morocco’s preparation for Ramadan.