Hacker Newsnew | past | comments | ask | show | jobs | submit | kkapelon's commentslogin

> Your circuit breakers don't talk to each other.

Doesn't this suffer from the opposite problem though? There is a very brief hiccup for Stripe and instance 7 triggers the circuitbreaker. Then all other services stop trying to contact Stripe even though Stripe has recovered in the mean time. Or am I missing something about how your platform works?


Good question, that's exactly why the trip decision isn't based on a single instance seeing a few errors. Openfuse aggregates failure metrics across the fleet before making a decision.

So instance 7 seeing a brief hiccup doesn't trip anything, the breaker only opens when the collective signal crosses your threshold (e.g., 40% failure rate across all instances in a 30s window). A momentary blip from one instance doesn't affect the others.

And when it does trip, the half-open state sends controlled probe requests to test recovery, so if Stripe bounces back quickly, the breaker closes again automatically.


It is answered in the FAQ at the bottom of the page

"The SDK is fail-open by design. If our service is unreachable, it falls back to the last known breaker state.

If no state has ever been cached (e.g., a cold start with no connectivity), it defaults to closed, meaning your protected calls keep executing normally. Your app is never blocked by Openfuse unavailability."


Yup, that is true for both Cloud and Self-hosted, it never blocks any executions by any external factors other than the breaker is KNOWN as open. The state sync and the hot path are 2 completely separated flows.

Feel free to take a look at the SDK code if you want to, it's open :) https://github.com/openfuseio/openfuse-sdk-node

There is also netmaker

It is still baffling to me why we need AGENTS.md

Any well-maintained project should already have a CONTRIBUTING.md that has good information for both humans and agents.

Sometimes I actually start my sessions like this "please read the contributing.md file to understand how to build/test this project before making any code changes"


Just symlink CONTRIBUTING as AGENTS

This only works on systems that support symlinks. It also pollutes the root folder with more files.

I understand the sentiment, but it is really strange that the people that are pushing for agents.md haven't seen https://contributing.md/

Is it even mentioned at GitHub docs https://docs.github.com/en/communities/setting-up-your-proje...


If the harnesses had a simple system prompt "read repository level markdown and honor the house style"?

Think of the agent app store people's children man, it would be a sad Christmas.


Yes. Essentially a competitor to the hugely popular glinet routers but tied to the unifi ecosystem


>What more are we asking AI to do? And can a normal human do it?

1. Learn/Improve yourself with each action you take 2. Create better editions/versions of yourself 3. Solve problem in areas that you were not trained for simply by trial and error where you yourself decide if what you are doing is correct or wrong


> We have always agreed that a natural language compiler is theoretically possible

citation? source? Who is we?


> As long as you are good at reviewing code, spec-ing carefully, and make atomic changes - why would you not be using this basically all the time?

This implies that you are an expert/seasoned programmer. And not everybody is an expert on this industry (especially the reviewing code part).


I thought this was a forum for seasoned engineers? But yes, I agree that this widens the skill gap and makes the on-ramp steeper.


What happens if you work in a team?

If a team has one senior/seasoned person and 3 juniors will adopting ai be a total positive move? Or the senior person will just become the bottleneck for the junior devs?


"It just works" with Teltonika and Glinet as well. In most of the openwrt based routers multi-wan is already enabled. It is also very easy to do with TP-Link Omada (just enable a checkbox).

So, implying that Unifi is the only company that does this in an easy way is misleading marketing.

Comparing against Mikrotik is a very low bar.


You're refuting a point he didn't make.


There are several other companies (e.g. Teltonika, glinet) that offer similar solutions that can use OpenWrt today


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: