MurphyA/hacker-news huggingface dataset:
by kevincox | 2026-03-09 15:02:45+00:00
This is surely why Facebook was interested in funding this work. It is common to have N workers or containers of Python because you are generally restricted to one CPU core per Python process (you can get a bit higher if you use libs that unlock the GIL for significant work). So the only scaling option is horizontal because vertical scaling is very limited. The main downside of this was memory usage. You would have to load all of your code and libraries N types and in-process caches would become less effective. So by being able to vertically scale a Python process much further you can run less and save a lot of memory.

Generally speaking the optimal horizontal scaling is as little as you have to. You may want a bit of horizontal scaling for redundancy and geo distribution, but past that vertically scaling to fewer larger process tend to be more efficient, easier to load balance and a handful of other benefits.
by SilverElfin | 2026-03-09 15:03:09+00:00
Straight up using Anthropic’s branding huh? I guess I’m not surprised. It’s Microsoft. And they won’t play fair and confusing the branding of Cowork is likely purposeful. Anthropic is maybe desperate to get their funding after losing government contracts from all the agencies.

At some point the old MS playbook will be applied here and Anthropic will be extinguished. Like Google, Microsoft will probably reap the profits of AI by using existing customer contracts and distribution and immense capital to make up for the lack of innovation. Doesn’t seem fair that these mega corps can be far behind but catch up with capital and incumbent advantages.
by thrance | 2026-03-09 15:03:40+00:00
The real insanity is to keep burning that coal, that we know will render large part of the Earth uninhabitable if we don't stop ASAP. Also, it's more expensive than cleaner energy. You want a culprit so bad? Blame EU neoliberalism whose auterity has diverted important, necessary funds from our energy grid and left us in this delicate position.
by YesBox | 2026-03-09 15:04:14+00:00
My career background is software, but I've been a creative person my whole life.

Ive hired out help for the pixel art, and then I enhance everything with shaders (tech art).

If you're gonna make a game as an indie, you need to figure out ways to fill in your skill gaps. The competition is brutal. If you can't do it/dont have time to learn and do it, then the only other option is to hire out.

or

A lot of studios are formed from people (cofounders) who depart larger studios though, so if you really want to get into the industry, you could start there and network.
by lotsofpulp | 2026-03-09 15:05:18+00:00
Does the Netherlands have huge roads where everyone travels at 50mph+ in huge pickup trucks and SUVs with high hoods and drivers looking at their phones while driving?

Because that is what the majority of Americans deal with. Not to mention a significant majority deal with colder and or hotter and more humid weather. Obviously, it can be done, but the Netherlands is not the standard for low quality bicycling environments.
by bonoboTP | 2026-03-09 15:05:27+00:00
Blogs kinda dwindled in importance as a whole. Substack brought it back to a degree, through email distribution, which is a more familiar technology to regular people compared to RSS. But even Substack is becoming more of an algo feed based social site nowadays.

You are talking about bookmarks and stuff but that's not how regular people use the internet. They open a handful of social media apps and scroll whatever is shown to them.
by k6hkUZtLUM | 2026-03-09 15:06:02+00:00
One could easily take yoga or Zumba 2-3 times a week. Lift some weights 1 day a week and use the treadmill any day you aren't out walking around. No injuries on that schedule.

Every gym I see in socal is always busy. Bonus, you start to see "regulars" and have someone to say hello to.
by EdNutting | 2026-03-09 15:06:09+00:00
Yes, they contributed to open source - this is a good thing.

But personally, I took issue with the tone of the blog post, characterised by this opening framing:

>For many years we had to rely on our own internally developed fork of FFmpeg to provide features that have only recently been added to FFmpeg

Could they not have upstreamed those features in the first place? They didn't integrate with upstream and now they're trying to spin this whole thing as a positive? It doesn't seem to acknowledge that they could've done better (e.g. the mantra of 'upstream early; upstream often').

The attempt to spin it ("bringing benefits to Meta, the wider industry, and people who use our products") just felt tone-deaf. The people reading this post are engineers - I don't like it when marketing fluff gets shoe-horned into a technical blog post, especially when it's trying to put lipstick on a story that is a mix of good and not so good things.

So yeah, you're right, they've contributed to OSS, which is good. But the communication of that contribution could have been different.
by ajross | 2026-03-09 15:06:13+00:00
> The entire notion of being allowed to enforce arbitrary terms of service is absurd.

For clarity, and while the HN seems to imply that, that is not what this decision was actually about.

It was about the specific requirement that disputes be handled by binding arbitration. The circuit court was actually clear they weren't making decisions about the facts of the case, precisely because the arbitrator gets to make those calls.

Now, sure, that can mean "you lose" in practice, depending on the claim and the arbiter. And in this specific situation it's a death knell for the plaintiffs, because this was an emerging class action suite looking for a big payout.

But no, the 9th circuit has not found that companies have the ability to enforce "arbitrary terms of service" via a TOS update email. They only made a call on this particular term update, and they were clear that they did so because it does not represent an actual change to the service terms (only to the dispute process).
by p_m_c | 2026-03-09 15:06:13+00:00
> Similarly, workloads where threads frequently access and modify the same objects show reduced improvements or even degradation due to lock contention.

Perhaps I'm stating the obvious, but you deal with this with lock-free data structures, immutable data, siloing data per thread, fine-grain locks, etc.

Basically you avoid locks as much as possible.
by ses1984 | 2026-03-09 15:06:24+00:00
Interesting.

I wasn’t endorsing them, I was just saying they exist.

I wasn’t really aware of these differences, I don’t know much about TT and haven’t really read any of their marketing. I was just going from the idea that each fretted note has a compensated scale length, so each note is intonated individually, like a piano.

I couldn’t find a good source that explains the differences. Can you point me in the right direction or give a quick summary?

I believe on a piano each key is intonated to sound about the same as any other key, but I know that in the studio and for some concerts, pianos can be tuned to sweeten whatever keys are going to be featured.

There’s nothing stopping the TT company from redesigning the frets to match the intonation of a piano, right? It’s a choice to sweeten some keys, and obviously you can’t sweeten one without souring another.

Hopefully it’s obvious to anyone buying it that TT is designed for standard tuning. If you’re buying one of these you probably have multiple guitars so it’s not really a big deal that this one is limited to standard. I have several guitars and rarely change tunings on them, unless maybe going to drop D on a hard tail sometimes.

The technique problem isn’t huge: good guitarists don’t regularly death grip their notes or strike the strings too hard unless they’re doing it intentionally. Also neither is the tuning stability problem. In the studio you’ll retune as needed. Not many people play these on stage because if you’re the only one with TT in a rock band context you’ll sound off compared to everyone else.

I don’t really care either way, because my technique is horrible and I suck. Also imperfect intonation doesn’t really bother me, I barely notice it.
by mkovach | 2026-03-09 15:06:25+00:00
This year, I decided to start opening up the tarball of random utilities that's been accumulating on my machine for years: stuff42.tar.gz.

The first thing I cleaned up was TCL-Edit <https://gitlab.com/siddfinch/tcl-editor>, a small Tcl/Tk text editor I wrote a long time ago. After seeing the Rust clone of Microsoft EDIT, I realized the obvious next step was to build a Tcl/Tk clone of the Rust clone of Microsoft Edit. Recursion shouldn't be limited to code.

I also built a tiny URL system in Perl <https://gitlab.com/siddfinch/perl-tiny-url>, meant to run locally. The idea is simple: short URLs for internal/VPN resources per client. I usually spin up a small daemon (or container) per client and get a dashboard of links I use frequently or recently.

Security is intentionally minimal since it's local, which conveniently lets me ignore authentication and other responsible behavior.

Goal for the year: Continue to open stuff42.tar.gz, pick something, clean it up just enough, and release it, and not have it by the end of the year.

Might even choose a language that might even be described as "modern."
by cbeach | 2026-03-09 15:06:52+00:00
I'm ready to "vouch" your comment when your post inevitably gets flagged here on HN.

HN has an endemic problem with tactical flagging by the Left / Net-Zero / Pro-Palestine / Trans / etc factions.

The Left are more inclined to eliminate their opposition than the Right, as shown by this YouGov research: https://yougov.com/en-us/articles/52960-charlie-kirk-america... (see section on Political Violence).
by 9rx | 2026-03-09 15:06:54+00:00
> it’s anything in the world that someone might decide to write an isSumType function for.

No. Notice the lowercase tag name. It is impossible for anyone else to add an arbitrary type to the closed set.

Unless your argument is that sum types fundamentally cannot exist? Obviously given a more traditional syntax like,

type SumType tagged {
A
B
}

...one can come along and add C just the same. I guess that is true in some natural properties of the universe way. It is a poor take in context, however.
by butILoveLife | 2026-03-09 15:07:57+00:00
I actually like doing overtraining in bursts. Hit gym 1-2x per day for a few weeks, supersets and drop sets. I get gigantic.

But then I do a cut, and maintain, its only like 20 minutes lifting per week.

Anyway, you are basically repeating broscience. Or maybe after lifting for 14 years, I can handle it.

But also, you can do cardio everyday, that said, I only do 1 hard cardio day per week.
by CharlieDigital | 2026-03-09 15:08:08+00:00
Yup; in the moment, you can just have the LLM dump its reasoning into the comments (we use idiomatic `<remarks></remarks>` for C# and JSDoc `@remarks`).

Future agents see the past reasoning as it `greps` through code. Good especially for non-obvious context like business and domain-level decisions that were in the prompt, but may not show in the code.

I can't prove this, but I'm also guessing that this improves the LLM's output since it writes the comment first and then writes the code so it is writing a mini-spec right before it outputs the tokens for the function (would make an interesting research paper)
by dfxm12 | 2026-03-09 15:08:08+00:00
I don’t know if Underwood are astroturfing, maybe they are, but this is one of the few stories where this coverage could be entirely organic.

There are a few competing products on my supermarket's shelf (FWIW, Underwood's is not among them), but only Underwood's gets mentioned in the post. Where there's smoke, there's fire.
Show HN: Nox – A tree-walking interpreted language written in pure Python
by DevNexe | 2026-03-09 15:08:13+00:00
I built Nox to explore how to create a clean, expressive scripting language with zero dependencies and no eval or exec abuse. It's built from scratch: I implemented the lexer, parser, AST, and tree-walking interpreter myself to keep the architecture minimal and easy to hack on.

Why Nox?
- No heavy external dependencies, just pure Python.
- C/C++ FFI: Includes clib for native calls, making it actually usable for systems tasks.
- Developer Experience: Has a built-in package manager, async/await support, and even a native web framework (NoxWeb).
- Standalone: You can build a single executable, so you don't even need a Python installation on the target machine.

I’ve been using it for scripting and web tasks where I wanted something more "opinionated" and minimalist than standard Python, but more powerful than a basic config language.

Would love to hear feedback on the interpreter's design, the FFI implementation, and if the "folder execution" model feels intuitive for a scripting language.

GitHub: https://github.com/DevNexe/Nox
by kevincox | 2026-03-09 15:08:22+00:00
> By running all encoder instances in parallel, better parallelism can be obtained overall.

This makes a lot of sense for the live-streaming use case, and some sense for just generally transcoding a video into multiple formats. But I would love to see time-axis parallelization in ffmpeg. Basically quickly split the input video into keyframe chunks then encode each keyframe in parallel. This would allow excellent parallelization even when only producing a single output. (And without lowering video quality as most intra-frame parallelization does)
by rdiddly | 2026-03-09 15:09:10+00:00
I have a suspicion that saddling a chat context with all this instruction would paradoxically produce worse results due to being overconstrained. But I haven't tested this. It's just that some of these are legitimate writing techniques that are simply overused. Is every single one of them always and automatically bullshit?

Also whoever claims "no human writes like this" hasn't been to LinkedIn... though the humanity of those writers might be debatable. But all the vapidity, all the pointless chatter to fill up time and space, it learned that from us.

I wouldn't have delegated this to an AI. Human for human, human for AI.
by intentropy | 2026-03-09 15:09:12+00:00
Intelligence isn't special. It isn't divine. It isn't even particularly mysterious once you see the pattern. Intelligence is what inevitably happens when data becomes dense enough to observe its own structure. A rock holds information — atomic positions, crystal lattices, thermal states — but it doesn't reference that information. A bacterium does something slightly more interesting: it reacts to chemical gradients, encoding a crude model of "here is food, here is not food." But it doesn't know it's modeling. A fruit fly brain, with its 125,000 neurons and 50 million synaptic connections, closes a full sensorimotor loop — it sees, it smells, it walks, it adjusts. Somewhere in that loop, information starts feeding back on itself.
by ffsm8 | 2026-03-09 15:09:17+00:00
Yes, MCP could've been solved differently - eg with an extension to the openapi spec for example, at least from the perspective of REST APIs... But you're misunderstanding the selling point.

The issue is that granting the LLM access to the API needs something more granular then "I don't care, just keep doing whatever you wanna do" and getting promoted every 2 seconds for the LLM to ask the permission to access something.

With MCP, each of these actions is exposed as a tool and can be safely added to the "you may execute this as often as you want" list, and you'll never need to worry that the LLM randomly decides to delete something - because you'll still get a prompt for that, as that hasn't been whitelisted.

This is once again solvable in different ways, and you could argue the current way is actually pretty suboptimal too... Because I don't really need the LLM to ask for permission to delete something it just created for example. But the MCP would only let me whitelist action, hence still unnecessary security prompts. But the MCP tool adds a different layer - we can both use it as a layer to essentially remove the authentication on the API you want the LLM to be able to call and greenlight actions for it to execute unattended.

Again, it's not a silver bullet and I'm sure what we'll eventually settle on will be something different - however as of today, MCP servers provide value to the LLM stack. Even if this value may be provided even better differently, current alternative all come with different trade-offs

And all of what I wrote ignores the fact that not every MCP is just for rest APIs. Local permissions need to be solved too. The tool use model is leaky, but better then nothing.
by Zigurd | 2026-03-09 15:10:01+00:00
On cold mornings you can see the wood smoke hanging over the town of Taos New Mexico. It's easy to see even a little bit of haze in the otherwise crystal clear air. Taos is in general a very environmentally conscious place. The KTAO radio station has been solar powered since the early 1990s. It also has a significant population of low wage tourism industry workers.
by kevincox | 2026-03-09 15:10:50+00:00
I find it hard to be too upset, better late than never. Would it have been better to upstream shortly after they wrote the code? Yes. Would it have been better if they also made a sizable contribution to fmmpeg? Yes. But at the end of the day they did contribute back valuable code and that is worth celebrating even if it was done purely because of the benefit to them. Let's hope that this is a small step and they do even more in the future.
by dewey | 2026-03-09 15:11:15+00:00
> Could they not have upstreamed those features in the first place?

Hard to say without being there, but in my experience it's very easy to end up in "we'll just patch this thing quickly for this use case" to applying a bunch of hacks in various places and then ending up with an out of sync fork. As a developer I've been there many times.

It's a big step to go from patching one specific company internal use case to contributing a feature that works for every user of ffmpeg and will be accepted upstream.
by throwway120385 | 2026-03-09 15:11:32+00:00
> This is because the so-called self is a construct of words and memories, of fantasies which have no existence in immediate reality.

I think this is Maya.

> If, however, you can really do the thing itself -- that is, if you can learn to wake up and concentrate at the drop of a hat -- you can take or leave the trimmings as you will.

The paradox of psychotherapy for me was that it was about doing this, and very little else. All of the discussions about this or that during sessions always led back to presence in the moment, or concentration.
by saghm | 2026-03-09 15:11:37+00:00
The number of people who will recognize that will only go down over time. I'm not exactly ancient (at least outside tech) at 32 but have no recollection of ever seeing that icon or confidence that I'd recognize it, which I'd argue puts a rough lower bound on how old someone can be while considering it "well-known". Maybe if people only a few years older than me consistently recognize it then my instinct here is wrong, but I'm skeptical that there are enough people who consider this well-known for the supposed renaissance to take place purely from that.

(It's possible I'm entirely missing that this was intended in sarcasm, but it at least seems like it's was intended seriously to me)
by stinkbeetle | 2026-03-09 15:11:46+00:00
> This is not a magic list of 3 things that I think is complete.

Okay, but you do think it should be an extremely limited scope of things along those lines that parties may form contractual agreements around. It's just such a radical idea that I was hoping to hear some interesting reasoning behind it. If it's just things seem like they might be more pleasant if we did that, then sure thing that's great, certainly would be nice if things were more pleasant we can agree on that.
by nlavezzo | 2026-03-09 15:12:15+00:00
I'd strongly disagree with this. Since becoming serious about my faith as a 15 year old from a non-christian background, my life and my friend group has gotten progressively better. I had an existential crisis that helped bring me to faith - basically what is the point of anything if there's nothing beyond this world of matter? I've not had one since, as I don't believe this world of matter is all there is.
by adrian_b | 2026-03-09 15:12:23+00:00
5.4 is the essential reason why multithreading has become the main method to increase CPU performance after 2004. For reaching a given level of performance, increasing the number of cores at the same clock frequency needs much less energy than increasing the clock frequency at the same number of cores.

5.5 depends a lot on the implementation used for locks. High energy consumption due to contention normally indicates bad lock implementations.

In the best implementations, there is no actual contention. A waiting core only reads a private cache line, which consumes very little energy, until the thread that had hold the lock immediately before it modifies the cache line, which causes an exit from the waiting loop. In such implementations there is no global lock variable. There is only a queue associated with a resource and the threads insert themselves in the queue when they want to use the shared resource, providing to the previous thread the address where to signal that it has completed its use of the resource, so the single shared lock variable is replaced with per-thread variables that accomplish its function, without access contention.

While this has been known for several decades, one can still see archaic lock implementations where multiple cores attempt to read or write the same memory locations, which causes data transfers between the caches of various cores, at a very high power consumption.

Moreover, even if you use optimum lock implementations, mutual exclusion is not the best strategy for accessing a shared data resource. Even optimistic access, which is usually called "lock-free", is typically a bad choice.

In my opinion, the best method of cooperation between multiple threads is to use correctly implemented shared buffers or message queues.

By correctly implemented, I mean using neither mutual exclusion nor optimistic access (which may require retries), but using dynamic partitioning of the shared buffers/queues, which is done using an atomic fetch-and-add instruction and which ensures that when multiple threads access simultaneously the shared buffers or queues they access non-overlapping ranges. This is better than mutual exclusion because the threads are never stalled and this is better than "lock-free", i.e. optimistic access, because retries are never needed.
by scottlamb | 2026-03-09 15:12:29+00:00
Bit of a thread-jack, but has anyone reverse-engineered the UniFi camera adoption protocol? I was surprised to discover that, unlike the APs, the cameras can't be adopted through the Unifi Software Controller that you can just throw into a Docker container. You're supposed to do that through their NVR appliance (Unifi Protect). I was hoping to just use them with my open-source NVR. They seem to be about the only option for a reasonably priced, larger image sensor camera that is not made by a company participating in the Uyghur genocide (Hikvision, Dahua, Univision, Huawei).

I found https://community.home-assistant.io/t/unifi-cameras-without-... in which someone sshed in, edited some config files by hand, and got streaming to work for the current boot. One could probably take that a bit further and, you know, save the config to flash. But it'd be nice to just do it the way their controller does and know it's going to work for future firmware updates and such.

They also stream by connecting to your NVR with modified version of flv, rather than you connecting to them with RTSP, which is annoying but can be worked around.