MurphyA/hacker-news huggingface dataset:
by avsm | 2026-03-07 17:53:45+00:00
VPNKit (the SLIRP component) has been remarkably bug free over the years, and hasn't been much of a burden overall.

There was another component that we didn't have room to cover in the article that has been very stable (for filesystem sharing between the container and the host) that has been endlessly criticised for being slow, but has never corrupted anyone's data! It's interesting that many users preferred potential-dataloss-but-speed using asynchronous IO, but only on desktop environments. I think Docker did the right thing by erring on the side of safety by default.
by jordanb | 2026-03-07 17:53:51+00:00
I was working for a company who tried to do that. We opened offices in Warsaw and Krakow and started trying to hire. We really couldn't get anyone, as everyone else had the same idea at the same time. People in those markets who were good and spoke english well basically had open offers from their choice of American firms.

I think we then were trying to open in Ukraine until the war.

The problem was that the talent pool just wasn't very deep and the thundering herd of American companies crowding in sucked it dry. Most of the people we did end up hiring in Poland were actually blue card holders from India.

After that we got bought by a PE firm who decided to do a GCC strategy focused on India, managed by McKinsey, it went as well as any other McKinsey lead outsourcing effort and the company is now spiraling.
by foresto | 2026-03-07 17:54:16+00:00
What stuff do you have in mind?

I was disappointed by Go's poor support for human-focused logging. The log module is so basic that one might as well just use Printf. The slog module technically offers line-based logging, but getting a traditional format out of it is painful, it lacks features that are common elsewhere, and it's significantly slower than its own json support. I can only guess that it was added as an afterthought. (To be fair, I suppose this might make sense if Go is intended only for enterprisey environments.)

I haven't explored enough of the stdlib yet to know what else that I might expect is not there. If you have a wish list, would you care to share it?
by johngossman | 2026-03-07 17:54:20+00:00
This verification problem is general.

As an experiment, I had Claude Cowork write a history book. I chose as subject a biography of Paolo Sarpi, a Venetian thinker most active in the early 17th century. I chose the subject because I know something about him, but am far from expert, because many of the sources in Italian, in which I am a beginner, and because many of the sources are behind paywalls, which does not mean the AIs haven't been trained on them.

I prompted it to cite and footnote all sources, avoid plagiarism and AI-style writing. After 5 hours, it was finished (amusingly, it generated JavaScript and emitted a DOCX). And then I read the book. There was still a lingering jauntiness and breathlessness ("Paolo Sarpi was a pivotal figure in European history!") but various online checkers did not detect AI writing or plagiarism. I spot checked the footnotes and dates. But clearly this was a huge job, especially since I couldn't see behind the paywalls (if I worked for a Uni I probably could).

Finally, I used Gemini Deep Research to confirm the historical facts and that all the cited sources exist. Gemini thought it was all good.

But how do I know Gemini didn't hallucinate the same things Claude did?

Definitely an incredible research tool. If I were actually writing such a book, this would be a big start. But verification would still be a huge effort.
by yieldcrv | 2026-03-07 17:54:41+00:00
> the company argued that uploading pirated books to other BitTorrent users during the torrent download process also qualifies as fair use ... as it is inherent to the protocol. In other words, the uploading wasn’t a choice, it was simply how the technology works.

as someone that's disabled upload when I'm downloading copyrighted material via bittorrent for decades, it is absolutely a choice

so there's that
Show HN: TeamShotsPro – AI team headshots from a selfie in 60 seconds
by Mvhaperen | 2026-03-07 17:54:55+00:00
Hey HN! I built TeamShotsPro because getting consistent, professional headshots for a team is a pain — coordinating schedules, hiring photographers, and the results still look mismatched.

TeamShotsPro lets each team member upload a single selfie and get a studio-quality AI headshot in about 60 seconds. The key is consistency: everyone gets the same lighting, background, and style so the team page actually looks cohesive.

Built with Next.js 15, Google Gemini for image generation, BullMQ for async processing, and Stripe for billing. The hard part was getting the AI to produce headshots that look natural rather than "AI-generated", we spent a lot of time on prompt engineering and post-processing.

Would love feedback on the product and the generation quality. Happy to answer any questions about the tech stack or approach!
by dlcarrier | 2026-03-07 17:55:15+00:00
That's my point, the software was getting bloated at least as fast as the CPUs were getting faster, so you had to upgrade to a new CPU every few years to run the latest software. With SSDs, there was a huge overlap in CPU speeds that may or may not have an SSD, so upgrading to one meant a huge performance boost, within the same set of runnable software.

Also, going from Sim City to Sim City 2000 was pre-bloat. Over the course of five years, the new version was significantly better than the original, but they both target the same 486 processor generation, which was brand new when the original SimCity was released, but rather old by the time SimCity 2000 was released. Another five years later, Sim City 3000 added minimal functionality, but required not just a Pentium processor, but a fast one.

I guess what I'm getting at is that a faster CPU means programs released after it will run better, but faster storage means that all programs, old and new, will run better.
by awinter-py | 2026-03-07 17:55:38+00:00
it's like that '11 rules for showrunning' doc where you need to operate at a level where you understand the product being made, and the people making it, and their capabilities, in order to make things come out well without touching them directly.

(https://okbjgm.weebly.com/uploads/3/1/5/0/31506003/11_laws_o...)

if you can do every job + parallelize + read fast, and you are only limited by the time it takes to type, claude is remarkable. I'm not superhuman in those ways but in the small domains where I am it has helped a lot; in other domains it has ramped me to 'working prototype' 10x faster than I could have alone, but the quality of output seems questionable and I'm not smart enough to improve it
by zimpenfish | 2026-03-07 17:55:46+00:00
> But no matter how cliché it sounds, it does get better with time.

For some, perhaps, but mine (25+ years) has not improved one jot. At best I've learnt to manage it with masking sounds (thanks to MyNoise) but it's always there waiting for a quiet moment.

Might be to do with how well your general auditory circuitry was working in the first place, mind - e.g. I've always had the "two noises at once tend toward garbage in my brain" problem (which made most social conversations almost impossible. FUN TIMES.) Given that implies my brain was already fairly borked for auditory processing, that might have an impact on whether it can eventually cope with tinnitus and/or whether it is more susceptible in the first place[0].

[0] Although I am 99% sure it's due to a large amount of loud gigs in small venues without any ear protection causing "mechanical damage" tinnitus.
by kube-system | 2026-03-07 17:56:01+00:00
You’re right that LLMs are going to push out jobs at the low end of the market. “Code monkey” type jobs are going to be displaced the same way computers displaced a lot of basic clerical and computational jobs.

But that doesn’t mean there won’t be entry level jobs, they will just have a different set of qualifications and expectations. Just like it’s hard to get a job doing arithmetic today without some other knowledge of the application, future jobs in computing are going to require people to understand things outside of the realm of programming alone. They are going to need to know more about the application of the code they write. It’ll be bad for developers who “just close Jira tickets” but problem solvers in a specific field will be okay.
by oso2k | 2026-03-07 17:56:02+00:00
There’s several other (well) known examples of the use of mujs.

There’s Artifex’s interpreter from muPDF. It’s also the basis of several JS related projects: https://mujs.com/

There’s also a lesser known interpreter: https://github.com/ccxvii/mujs

And IIRC, there was a CommonJS library of the same name.
Show HN: Python script that alerts when your CLI AI agent goes idle
by davecandi | 2026-03-07 17:56:26+00:00
Creator here. Built this after wasting hours switching to other tabs while Claude Code/Gemini sat idle waiting for permission.

Simple Python script that monitors terminal activity and plays a sound when your agent stops.

Demo video: https://youtu.be/cligunGJgwY

get it free on github: https://github.com/davecandi/vibechime
project page here https://davecandi.com/projects/vibechime

Would love feedback!
by willio58 | 2026-03-07 17:57:12+00:00
> This is why I think we're headed for systemic collapse.

Unfortunately I think the only thing that will save us long term is systematic collapse triggering mass social and political movements to tax the billionaires.

We have severe cost of living issues for so many Americans, yet we haven’t actually reached that cusp where large swaths of Americans literally start starving, or losing their homes.

Until then, normal Americans will happily consume and believe the lies of politicians saying “grocery prices are going down”, “gas prices are going down”.
by bmitch3020 | 2026-03-07 17:57:32+00:00
I've seen countless attempts to replace "docker build" and Dockerfile. They often want to give tighter control to the build, sometimes tightly binding to a package manager. But the Dockerfile has continued because of its flexibility. Starting from a known filesystem/distribution, copying some files in, and then running arbitrary commands within that filesystem mirrored so nicely what operations has been doing for a long time. And as ugly as that flexibility is, I think it will remain the dominant solution for quite a while longer.
by ineedasername | 2026-03-07 17:57:46+00:00
I’m not counting only soldiers. I didn’t pull these numbers out of thin air they’re not hard to find so I’m not going to take my time. I’ll say this: the difference isn’t small, hospitals don’t get bombed every day, and if you’re going to disagree with something that would be commonly known among knowledge among people familiar with a topic if you pause for a moment to reflect then the habit of checking to see if your instinct or sense of a thing is actually correct is a useful habit. Not least of which when something like bombing a hospital is now possible yes but destroying them has ever been so, or simply slaughtering their residents as you march through, and there were far fewer norms against that sort of thing. Deliberate slaughter of non combatants also isn’t new. Prohibitions against it arose for a good reason and strong precedent of the practice from times where marching armies were more common and therefore systematic slaughter of this sort more convenient to those inclined.

These too are not unobvious things to if you consider possible modes of death by or adjacent to military campaigns and they too are also not hard to find estimates for.
by zbentley | 2026-03-07 17:57:54+00:00
> fixing the actual problem is just too hard.

I think it’s laziness, not difficulty. That’s not meant to be snide or glib: I think gaining expertise in how to package and deploy non-containerized applications isn’t difficult or unattainable for most engineers; rather, it’s tedious and specialized work to gain that expertise, and Docker allowed much of the field to skip doing it.

That’s not good or bad per se, but I do think it’s different from “pre-container deployment was hard”. Pre-container deployment was neglected and not widely recognized as a specialty that needed to be cultivated, so most shops sucked at it. That’s not the same as “hard”.
by heavyset_go | 2026-03-07 17:59:38+00:00
I'd be embarassed to put my name on AI prose without a disclaimer and I'd also be annoyed to read it as a reader.

IMO it's insulting to the audience, it says your time and attention is not worthy of the author's own time and attention spent putting their own thoughts in their own words.

If you're going to do that at least mention it's LLM output or just give me your outline prompts. I don't care what your LLM has to say, I'm capable of prompting your outline in my own model myself if I feel like it.
by lopatin | 2026-03-07 17:59:58+00:00
Without it you likely would have been in the same quagmire, but just slower?

It could have taken you years to realize that "oh I'm just exploring stuff and have no output".

Set an ambitious goal that is achievable using Claude Code, and focus on delivering it. Even if it doesn't turn out to be a hit, the experience of releasing it and using AI to accelerate it, will be a talking point to your 10-year-older self.
by piker | 2026-03-07 18:00:05+00:00
> user: lydionfinance

> created: 64 days ago

> debugger

> 3 commits

> emoji soup README

I won't flag it because I caught (legit) flak for that last time, but the above should be sufficient information for the voters to asses. Upvoting this is poisonous to Hacker News.

I do think it's worthy of flagging.
by RossC17331 | 2026-03-07 18:00:06+00:00
Hi HN,

I built Leonardo as a lightweight Linux video converter built on top of FFmpeg.

The goal was to simplify common creator workflows without typing long FFmpeg commands.

Presets include:
• DaVinci Resolve MOV workflow
• YouTube H.264
• OBS remux
• TikTok 9:16 vertical auto crop (fixed in 10.0.13)

It's distributed as a Linux AppImage and includes built-in HTML help documentation.

Project page:
https://bytesbreadbbq.com/leonardo/
by onion2k | 2026-03-07 18:00:07+00:00
Analysis cannot be X in ~1900's vs. x + y these days -> "Oh wow things have changed".

Very true. I'm not suggesting that we should ignore the tens of millions killed in wars and as the indirect result of wars decades ago. I'm only saying that there's still a really large number of people killed. If you take a war like World War 2 that resulted in an estimated 10 million deaths per year (60 million dead over 6 years) we've only reduced that by a factor of 10 (at most, because the study I linked to is not all conflicts) which isn't very much, and that's still a catastrophic and tragic number of deaths.
by scythe | 2026-03-07 18:00:25+00:00
Yeah that's the conventional dose rate effect, not the FLASH effect. The FLASH effect happens on timescales so short that ordinary considerations like the cell cycle or DNA repair mechanisms are inherently ruled out. Instead it might have to do with the type of radical species that form in normal cells versus tumors, possibly related to oxygenation, pH, glycolysis byproducts, etc.

The first interaction of radiation with tissue is usually this:

H2O + ħv >> H2O+ + e- (fugitive)

The radical ion H2O+ is extremely reactive and usually protonates another water molecule immediately:

H2O+ + H2O >> H3O+ + OH*

The hydroxyl radical has a half life of about a nanosecond and will usually be the main "reagent", diffusing until it runs into an organic molecule which will be oxidized and thus degraded. At high enough dose rates, the peak concentration of hydroxyl radicals and more stable radicals like superoxide could be much higher, leading to "nonlinear" effects, i.e. byproducts of multiple radicals interacting with each other or a protein.
by nautilus12 | 2026-03-07 18:00:27+00:00
Worked for famous Japanese data platform for a few years. The Japanese engineers were collegial but some were actually Hikikomori focused on very narrow things and were very nitpicky about details that wouldn't have ultimately mattered. In the Tokyo office people lived to work and I saw people regularly sleeping at their desk after having stayed out all night for obligatory whiskey outing with colleagues and arriving at the office at 6 am as expected. The San Fran office was the opposite, very sloppy standards people, getting in at noon and staying up late to meet deadlines. The impedence mismatch between the two environments was almost unbearable.
by garciansmith | 2026-03-07 18:00:39+00:00
I think you are correct to state that KDE can still improve in a lot of ways. Although I personally find the new screenshot tools to be great: I now use them a lot more than I used to, especially to annotate things.

I was responding to your belief that somehow Gnome is better or that "Gnome just works exactly like you'd expect it to," as you stated. My point is that it does not. And you might not find Desktop icons useful, but I (and millions of other people!) use them every day and have for decades. I could drag and drop icons on the desktop of my family's first computer, a Mac that ran System 7 in the early 1990s. And then our Windows 95 box. And then Windows 98, and 2000, and XP, and a laptop that ran Vista. And then that laptop running Ubuntu with Gnome 2, and then Ubuntu Unity, and then Gnome 3... until Gnome decided, nope, sorry!
by amluto | 2026-03-07 18:00:53+00:00
Even completely ignoring the issues of language-centric vs data-format-centric serializers, your list is missing two very notable entries from my list: Arrow and Parquet. Both of them go to quite some lengths to efficiently handle optional/missing data efficiently. (I haven’t personally used either one for large data sets, but I have played with them. I think you’ll find that Arrow IPC / Feather (why can’t they just pick one name?) has excellent performance for the actual serialization and deserialization part as long as you do several rows at a time, but Parquet might win for table scans depending on the underlying storage medium.). Both of them are, quite specifically, the result of years of research into storing longish arrays of wide structures with potentially complex shapes and lots of missing data efficiently.
by VanTodi | 2026-03-07 18:00:55+00:00
I've come to the point where I think generated code is nothing better than a random package I install.
Did I read it all and just accepted what was promised? Yes
Can it bite me in the butt somewhere down the road? Probably, but I currently at least have more doubt about the generated code than a random package I picked up somewhere on git which readme I just partly skipped over.
by grey-area | 2026-03-07 18:01:00+00:00
Well two things to me feel clunky, first is less serious but leads to lots of verbosity:

1. if err != nil is verbose and distracting and happens a lot. I'd prefer say Ian Lance Taylor's suggestion of something like this where you're just going to return it:

// returns error if non-nil, otherwise continue

data, err := os.ReadFile(path) ?

vs standard boilerplate which has to return other stuff along with the error:

data, err := os.ReadFile(path)

if err != nil {

return x,y,z,err

}

The second is a problem of culture more than anything but the stdlib is to blame:

2. The errors pkg and error interface has very basic string errors. This is used throughout the stdlib and of course in a lot of go code so we are forced to interact with it. It also encourages people to string match on errors to identify them etc etc. Yes those people are naughty but it is understandable, if given this very basic instrument they will use it. Yes you can use your own error types and error interfaces but this then creates interop problems and inevitably many pkgs you use return the error interface. I use my own error types, but still have to use error a lot due to stdlib etc.

So these are not things that end users of the language can fix.
by j1elo | 2026-03-07 18:01:13+00:00
As a Kodi user, I must say it is very good on its core, and very bad on the addons side (which arguably is the part for which it gets recommended mostly)

It forces its limited model of text-based folders-with-files to everything. Also it's all Python, and I don't know if it's me but I always find quality issues first in Python projects than anything else. Error control is usually very lacking, and it's so frequent to see error pop-ups showing on here and there. You enter a menu and the first entry selected is ".." which is to go back to the previous menu (poor UX). All in all, Kodi for me has always been a player with good tech (it all basically works, surround sound, codecs, integration with hardware, etc), exposed as very amateurish UI experiences.
by avsm | 2026-03-07 18:01:20+00:00
An extremely random fact I noticed when writing the companion article [1] to this (an OCaml experience report):

"Docker, Guix and NixOS (stable) all had their first releases
during 2013, making that a bumper year for packaging aficionados."

Now we get coding agent updates every week, but has there been a similar year since 2013 where multiple great projects all came out at the same time?

[1]: https://anil.recoil.org/papers/2025-docker-icfp.pdf
by zbentley | 2026-03-07 18:01:28+00:00
But they’re roughly the same paradigm as docker, right? My understanding of the Nix approach is that it’s still reproducing most of a user land/filesystem in a captive/separate/sandbox environment. Like, docker is using namespaces for more stuff, Nix has a heavier emphasis on reproducibility/determinism, but … they’re both still throwing in the towel on deploying directly on the underlying OS’s userland (unless you go all the way to nixOS) and shipping what amounts to a filesystem in a box, no?
by amelius | 2026-03-07 18:01:29+00:00
There have been overclockers who reached 9GHz using liquid helium.

It's simply impossible at room temperatures.

Also you will run into interconnect speed issues, since 10GHz corresponds to .1 nanoseconds which corresponds to 3 centimeters (assuming lightspeed, in reality this is lower).

So sadly, we'll be stuck in this "clock-speed winter" for a little longer.