MurphyA/hacker-news huggingface dataset:
by dxdm | 2026-02-22 12:56:02+00:00
For the purposes of this discussion, I'd say a "long-lived" branch is one that runs into merge conflicts with other code that's been developed in ignorance of the branch's contents, or a branch that acquires enough code to not be easily reviewable in its entirety. But generally, I'd say if it lives longer than a day, that's getting too old. (Exceptions apply.)

Code should live in main/master and be in a production environment as soon as possible, but it does not have to run for all, most or even any customers/clients from the start. You can gate it behind feature switches, preprocessor directives, global constants, whatever. As long as it has an active purpose and is being developed further, it is not dead. Ideally, it will have tests.

The result of merging back to main often is that other changes will be made in awareness of your new code, and all merging will happen organically and in small increments. You also get to develop complex features bit by bit, in a way that can be verified in a real environment in a controlled way. And everything can be deployed anytime, which should happen often.

Being able to verify incrementally and get quick feedback lowers the risk of otherwise releasing a hitherto completely untested large feature into the wild in one go.

This does not absolve you from making sure that your changes actually work as intended. That will be easier if you portion the work into smaller chunks that are easier to understand than a whole, complex, all-or-nothing feature.

Of course you will still have to make sure that your small chunks fit together and make up a good "whole". However, the idea is that you're doing this exact work anyway when developing a larger feature on the side, but you might as well cut it up to deliver in much smaller increments.

This approach has its own costs and drawbacks, but in my experience it often produces a substantial net-reduction in friction and accumulated complexity and risk, and it keeps things moving, which is a benefit on its own. This is from my perspective in backend development, and it will not apply universally, but widely. Essentially, whenever you can get away with it, you should strive to deliver like this.
by GTP | 2026-02-22 12:56:10+00:00
My guess is that management would see little to no ROI, as the average user is already able now to schedule tasks using one of these AI agents. Which is killing a mosquito using an energy-hungry bazooka, but the general public doesn't seem to care. And I myself have to admit that I don't have a clear opinion on all this, as I have many complaints, but in these days I'm trying to use AI agents for some side projects.
by solatic | 2026-02-22 12:57:35+00:00
I have no idea how you got that from my comment. How much you make, how much you save, how much you spend, and how much you give away are all independent, and neither is it a zero-sum pie (for example, sometimes investments go down in value, and sometimes the line between giving away and spending is blurry).

To answer your question directly, $70k income is independent of the cost of living in high cost of living cities (like NYC or SF) vs. low cost of living areas. If you make $70k/year in NYC, no you don't have the spare income to max out 401k/HSA. If you make $70k/year working for Walmart in Bentonville, Arkansas, then yeah, I expect that you ought to be able to max them out.
by qoez | 2026-02-22 12:58:05+00:00
> It took them two months, to develop chip for Llama 3.1 8B. In the AI world where one week is a year, it's super slow. But in a world of custom chips, this is supposed to be insanely fast.

LLama 3.1 is like 2 years at this point. Taking two months to convert a model that only updates every 2 years is very fast
Why Moltbook Failed: The Lack of Identity in Autonomous AI Agents
by benstarslett | 2026-02-22 12:59:45+00:00
The collapse of Moltbook (characterized by API key leaks, agent impersonation, and the revelation that many "autonomous" bots were actually human-operated) is not just a security incident. It is a structural failure: the platform lacked any persistent, cryptographically verifiable identity for its AI agents.
Without a registry serving as a Source of Truth — providing data on who owns the agent, who is responsible for it, and how to audit it — any agentic ecosystem will rapidly descend into duplication, spoofing, spam, and fraud. Moltbook is the textbook example.
The Hindustan Times reported on the incident and included my technical commentary, which is based on the principles described in the book "I Am Your AIB" by Jay J. Springpeace (published January 16, 2026 — well before the launch of Moltbook): https://www.hindustantimes.com/world-news/us-news/what-is-moltbook-5-key-facts-about-the-ai-only-social-media-platform-101769833804190.html
• Cryptographic Identity: AI agents must have a signed, unfalsifiable identity anchored in a registry.
• Real-time Monitoring: Platforms require behavioral tracking with the ability to immediately suspend anomalous agents.
• Sandboxing: Agent logic must be isolated from sensitive system components to prevent leaks or unauthorized access.
The book argues that autonomous systems without a layer of identity and accountability are inherently dangerous and proposes AIBSN (Artificial Intelligent Being Serial Number) — a decentralized registration framework stored on Arweave.
Technical Standard: AIBSN.org
________________________________________
Discussion Points:
1. Are you already using some form of persistent identity for your agents (LangGraph, AutoGen, CrewAI…)?
2. Are centralized API keys and rate limiting sufficient, or do we need a robust provenance chain for all AI actions?
3. Is AIBSN overkill, or is it exactly what was missing in Moltbook and similar experiments?
I am looking forward to technical critiques, alternatives, and practical experiences. Thank you for the discussion!
by gmuslera | 2026-02-22 13:00:43+00:00
Another factor that as far I remember was present in the novel was technological acceleration, by the time you detected the first tries of "turning on the lights" of an emerging civilization many light years away, that civilization is not an emerging one anymore, and even more by the time you can get there, and they may eventually be able to do something to harm or destroy your own civilization, so it is not something that should be left unchecked.

And technological acceleration is a constant in that universe, the attackers were just a bit ahead of us in technological advancement, lets say a few hundred years, not the millions or billions of years ahead of the very bad ones.
by chris_wot | 2026-02-22 13:01:31+00:00
I am currently trying to wrangle this UI. It is called VCL and it was initially created in the early 1990s.

If you want to see my efforts, I have a number of branches on github:

Phase 5 can be located here:

https://github.com/chrissherlock/libreoffice-experimental/tr...

Check the source here:

https://github.com/chrissherlock/libreoffice-experimental/tr...

in particular keep an eye on:

https://github.com/chrissherlock/libreoffice-experimental/tr...
by AMARCOVECCHIO99 | 2026-02-22 13:02:11+00:00
Haven't used it but just checked it out — interesting project. Different goals though.

Raptor configures Claude Code as a security agent for active pentesting and adversarial research. It's an LLM doing dynamic security analysis.

Prodlint is the opposite direction with deterministic static analysis, no LLM in the loop. 52 rules that check for the structural patterns AI coding tools consistently get wrong (leaked secrets, missing rate limiting, hallucinated imports, etc.). Same result every time, under 100ms, works offline.
by throwaway2037 | 2026-02-22 13:02:35+00:00
Absolutely. I don't know what legal jurisdiction they are subject to, but I could imagine that someone tries to sue an EU division/outpost in an EU court under a GPDR-type of petition, these posts would be submitted as evidence. One could easily argue the CEO is acting on behalf of the company by posting using their real name. (Let's presume there is no identity fraud for these posts.)

And don't forget that Elon Musk was tried in the US for defamation after making a bunch of posts on Twitter against some UK citizens. Assuming that you are posting under your real name, you are definitely legally responsible for those words.
by cebert | 2026-02-22 13:03:19+00:00
API tooling companies are going to have a harder time squeezing every ounce of profit out of their products. With AI, it’s now very feasible to build your own API testing harnesses, documentation generators, or compliance/standards tools. The bar for “good enough” internal tooling has dropped significantly.

AI makes it harder for vendors to enshitify products by adding bloat, gating features, or inflating enterprise pricing, without losing customers. Teams can spin up internal alternatives quickly.

I’d argue this extends beyond API tooling. In our organization, we considered FinOps tools like Vantage or ProsperOps to manage cloud costs. They can get expensive. Instead, we piloted having Claude build a focused internal tool that delivers similar outputs but only includes the features we actually need. It turned out to be surprisingly effective. Not identical, but good enough without the enshitified enterprise price tag.

AI is shifting buy vs. build decisions. Vendors with real differentiation will be fine. Those relying on pricing complexity or inertia may struggle. They’ll need to treat their customers better instead of focusing solely on short term profit if they want to exist more than a few years.
Show HN: Pq – Simple, durable background tasks in Python using Postgres
by ricwo | 2026-02-22 13:03:54+00:00
At work we were using python-rq for background tasks. It does the job for simple things, but we kept bumping into limitations. We needed to schedule tasks hours / days out and trust they'd survive a restart. We wanted periodic tasks with proper overlap control. So we built a scheduling / enqueuing system around Postgres to bring these durability capabilities to python-rq. This worked fine for a while but was trickier to reason about due to its more complicated architecture (we'd run two separate services just for getting jobs from Postgres into the rq Redis queue, plus N actual task workers).

pq is a simpler approach: It's a Postgres-backed background-task library for Python, using SELECT ... FOR UPDATE SKIP LOCKED for concurrency safety. You just run your N task workers, that's it. The stuff I think is worth knowing about:
- Transactional enqueueing -- you can enqueue a task inside the same DB transaction as your writes. If the transaction rolls back, the task never exists. This is the thing Redis literally can't give you.
Fork isolation -- every task runs in a forked child process. If it OOMs, segfaults, or leaks memory, the worker just keeps going. The parent monitors via os.wait4() and handles timeouts, OOM kills, and crashes cleanly.
- Periodic tasks -- intervals or cron expressions, with overlap control (skip the tick if the previous run is still going), pause/resume without deleting the schedule.
Priority queues -- five levels from BATCH to CRITICAL. You can dedicate workers to only process tasks with specific priorities.
- Three tables in your main database schema: pq_tasks for one-off tasks, pq_periodic for periodic tasks and pq_alembic_version to track its own schema version (pq manages its own migrations).

There's also client IDs for idempotency and correlation with other tables in your application DB, upsert for debouncing (only the latest version of a task runs), lifecycle hooks that execute in the forked child (useful for fork-unsafe stuff like OpenTelemetry), and async task support.

What it won't do: high throughput (you're polling Postgres). If you need 10k+ tasks/sec or complex DAGs, use something else. For the kind of workload most apps actually have, it's probably sufficient.

pip install python-pq // uv add python-rq
repo at https://github.com/ricwo/pq, docs at https://ricwo.github.io/pq
by sarchertech | 2026-02-22 13:03:54+00:00
>rebuilt from scratch

I have actually encountered multiple people proposing that. People in the camp of LLMs are the new high level compiler and code is assembly language.

That’s what prompted this entire are compilers deterministic article.

But ignoring whether it’s regenerated from scratch, when you ask an agent to add minor functionality, it will regularly change existing unrelated functionality.

Some of that is accidental, and could theoretically be solved. For example agents when refactoring won’t copy and paste existing code, they will rewrite it from scratch and frequently change it. Some of it is a required because systems are intertwined.

If the application is small enough you can get away with just trying the results to build confidence. However for any non-trivial application combinatorics explosion means that this stops working very quickly. This has been understood for decades.

> My point was that "didn't look at the code, looked at the app and gave feature requests and tried the results" is a way of building applications that essentially anyone who doesn't code has been doing all along.

That is not building applications. That is delegating building applications to a trusted team of humans. If that trusted team of humans are essentially junior programmers with no agency or ability to learn and improve, your app will fail.

Imagine being a product manager with a team of 100 off shore junior developers that rotate out every day. You could 100% build something useful with that setup. But anything more complex than a todo app would eventually collapse under the chaos.
by kurouna | 2026-02-22 13:04:05+00:00
You might be right! For those who love Emacs for its Lisp environment, this editor is probably not useful at all.

I just made this for people like me, who instinctively press C-f instead of the right arrow key, but just want to start typing immediately without any setup.

As for the input latency, it might indeed be slower than native editors like Notepad. However, by using a custom Piece Table and virtual rendering, I personally don't feel the delay on a modern PC, and I am very satisfied with the responsiveness for my daily use.
by dingobp | 2026-02-22 13:04:25+00:00
I'm a geoscience student and built this over the past few weeks as a side project. It's a daily geography puzzle where you guess the mystery world capital in 6 tries.
Each guess returns: distance in km (Haversine formula), compass bearing (spherical trig), and attribute matches for continent, hemisphere, coastal status and population range. Same capital for all players worldwide each day — picked deterministically by hashing the date against the capitals array, no server or database needed.
The share card was fun to build — instead of just copying text to clipboard it renders a boarding pass image on the client using the Canvas API, then uses the native Web Share API to attach the image directly to WhatsApp/iMessage. The departure city is your first guess, destination is always "???" so no spoilers.
Stack: Next.js 14, TypeScript, Tailwind, react-simple-maps, canvas-confetti. Deployed on Vercel free tier.
https://capitalle.app
Happy to go into detail on any of the technical decisions.
by megamalloc | 2026-02-22 13:05:22+00:00
Many, many years ago I was a dedicated Emacs user.

My recollection is that there was a very lightweight binary that would launch a single window utilising an existing Emacs process that (of course) you usually alrwady had running, to show a dedicated window for editing a single file - which is Notepad's raison d'etre. So as a Notepad replacement I can't really see a place in the world for something like this.

I am not in any way competent to comment on CJK issues in Emacs as I can't do any of those languages. I can appreciate the desire to address those.

To answer OP's question, I doubt there is much demand for a knobbled Emacs like this, but on the other hand, I think you should do open source software primarily for yourself because doing it for others' sake will grind you down. But if what really pleases you is to make an impact for a lot of other people, directing your energies into solving CJK issues in Emacs itself would be a lot more impactful (though I am sure a lot more challenging too).
by ajross | 2026-02-22 13:05:42+00:00
> all the Xorg politics nonsense

Uh... Xorg is packaged by FreeBSD too...

Really the whole theme that (from the article) "FreeBSD ships as a complete, coherent OS" is belied by this kind of nonsense. No, it's not. Or, sure, it is, but in exactly the same way that Debian or whatever is. It's a big soup of some local software and a huge ton of upstream dependencies curated for shipment together. Just like a Linux distro.

And, obviously, almost all those upstream dependences are exactly the same. Yet somehow the BSD folks think there's some magic to the ports stuff that the Linux folks don't understand. Well, there isn't. And honestly to the extent there's a delta in packaging sophistication, the Linux folks tend to be ahead (c.f. Nix, for example).
by KronisLV | 2026-02-22 13:06:56+00:00
> the container stack complexity

I'm using either Docker Compose or Docker Swarm without Kubernetes, and there's not that much of it, to be honest. My "ingress" is just an Apache2 container that's bound to 80/443 and my storage is either volumes or bind mounts, with no need for more complexity there.

> The jails vs containers framing is interesting but I think it misses why Docker actually won. It wasn't the isolation tech. It was the ecosystem: Dockerfiles as executable documentation, a public registry, and compose for local dev. You could pull an image and have something running in 30 seconds without understanding anything about cgroups or namespaces.

So where's Jailsfiles? Where's Jail Hub (maybe naming needs a bit of work)? Where's Jail Desktop or Jail Compose or Jail Swarm or Jailbernetes?

It feels like either the people behind the various BSDs don't care much for what allowed Docker to win, or they're unable to compete with it, which is a shame, because it'd probably be somewhere between a single and double digit percent userbase growth if they decided to do it and got it right. They already have some of the foundational tech, so why not the UX and the rest of it?
by jongjong | 2026-02-22 13:07:27+00:00
Unfortunately, I don't use Stripe products because they discriminated against me by blocking my account because my project used a Blockchain (which I built myself) as an authentication mechanism.

It's discrimination because Blockchain tech is part of my religious beliefs... Why is it so that less intelligent people who believe that there is a man in the sky watching over them have protection against discrimination but I don't? Yet my beliefs are grounded in science and an actual understanding of our socio-economic system. I deserve more protection, not less!

Does the law require that one's beliefs be irrational in order to benefit from discrimination protections?
Why Moltbook Failed: The Lack of Identity in Autonomous AI Agents
by benstarslett | 2026-02-22 13:07:50+00:00
The collapse of Moltbook (API key leaks, agent impersonation, and human-operated bots) isn't just a security incident. It is a structural failure: the platform lacked any persistent, cryptographically verifiable identity for its AI agents.

Without a registry serving as a Source of Truth — providing data on ownership and accountability — any agentic ecosystem descends into chaos. Moltbook is the textbook example.

The Hindustan Times reported on this and included my technical commentary, which is based on principles from the book "I Am Your AIB" by Jay J. Springpeace (published January 16, 2026):

https://www.hindustantimes.com/world-news/us-news/what-is-moltbook-5-key-facts-about-the-ai-only-social-media-platform-101769833804190.html

The book argues for:

Cryptographic Identity: Agents must have a signed identity anchored in a registry.

Real-time Monitoring: Immediate suspension of anomalous behaviors.

Sandboxing: Isolation of agent logic from sensitive components.

This is why we need a decentralized registration framework like AIBSN (Artificial Intelligent Being Serial Number) stored on Arweave.

Technical Standard: AIBSN.org

Discussion Points:

Are you using persistent identity for agents (LangGraph, AutoGen, CrewAI)?

Are centralized API keys enough, or do we need a robust provenance chain?

Is AIBSN (aibsn.org) overkill, or exactly what Moltbook was missing?

Looking forward to technical critiques and practical experiences.
by bonesss | 2026-02-22 13:07:52+00:00
We’ve also got to consider the fourth dimension, what happens over time.

Salesforce is getting LLM superpowers at the same time the Enterprise is, so customizing and maintaining and extending Salesforce are all getting cheaper and better and easier for customers, consultants, and Salesforce in parallel.

Unless the LLMs are managing the entire process there’s still a value proposition around liability, focus, feature updates, integrations, etc. Over time that tech should make Salesforce get way cheaper, or, start helping them upsell bigger and badder Sales things that are harder to recreate.

And, big picture, the LLMs are well trained on Salesforce API code. Homegrown “free” versus industry-standard with clear billing, whatever we know versus man-decades of learning at a vendor, months of effort and all the risk & liability versus turnkey with built-in escape goats… at some point you’re paying money not to own, not to learn, not to be distracted, and to have jerks to sue if something goes bad.
by mejutoco | 2026-02-22 13:08:29+00:00
My point is that the underlying incentives are exactly the same. I dont think the rules have changed at all. If you are expedia you could always give an api to search forhotels, but why commoditize yourself? Same with agents.

Ryanair recently had a court case with some meta travel website because they were selling their flights. Ryanair wants to sell you the insurance and extras, and they can only do so controlling the experience.

My prediction is, like apis, there will be some years of extra access for agents, followed by locking moats for their own experience.
Orvia – Spin up a real-time room, share files, leave – everything disappears
by yc_surajkr | 2026-02-22 13:08:44+00:00
I built Orvia — a real-time, temporary collaboration room for instant conversations and fast media sharing.

~200 users have tried it so far. The main feedback wasn’t about missing features, but UX:

UI felt too “hacker tool”

Empty rooms felt awkward

Too many visible actions

So I redesigned it to feel calmer and frictionless.

The idea is simple:
Create a room → Share the link → Talk & share files → Leave → Room disappears.

No accounts.
No setup.
No stored history.

It’s built for quick, private, zero-overhead collaboration — not persistent communities.

Would really appreciate honest feedback on UX and real-time experience or any missing feature.

url - https://orvia.live