seuros

They can't! They waiting for a token reset.

I built this to give people that can't refrain from publishing packages to official registries, a way to purge that need.

The platform will be totally controlled by AI, most of its source is already opensource.

I will never sell it, or let any company inject their agenda on it.

I hope this will fix some issues we have in the ecosystem.

This is crap .. the driver is untested piece of hallucination.

I have exact MacBook and chipset that op is claiming to support.

The driver doesn't even compile without modifications.

It attach to the device, but you can't scan, associate or do anything.

Basically the whole driver is stubbed.

Author here: Let’s be clear on backups:

Yes, I had backups everywhere. Across providers, in different countries. But I built a system tied to my AWS account number, my instances, my IDs, my workflows.

When that account went down, all those “other” backups were just dead noise encrypted forever. Bringing them up to the story only invites the 'just use your other backups' fallback, and ignores the real fragility of centralized dependencies.

It is like this: the UK still maintains BBC Radio 4’s Analogue Emergency Broadcast—a signal so vital that if it’s cut, UK nuclear submarines and missile silos automatically trigger retaliation. No questions asked. That's how much stakes they place on a reliable signal.

If your primary analogue link fails, the world ends. That's precisely how I felt when AWS pulled my account, because I’d tied my critical system to a single point of failure. If the account was just Read only, i will waited because i could have access to my data and rotated keys.

AWS is the apex cloud provider on the planet. This isnt about redundancy or best practices.

it's about how much trust and infrastructure we willingly lend to one system.

Remember that if BBC Radio 4 signal get to fail for some reasons, the world will get nuked, only cockroaches will survive… and your RDS and EC2 billing fees.

Thank you for your concern, and I appreciate the nuance in your take.

Yes, it is totally possible that AWS monitors blogs and forums for early damage control, like your company does.

But we shouldn’t paint it like I was bailed out by some algorithmic PR radar and nothing else.

Let’s not fall into the “Fuk the police” style of thinking where every action is assumed to be manipulation. Tarus didn’t reach out like a Scientology agent demanding I take the post down or warning me of consequences.

He came with empathy, internal leverage, and actually made things move.

When before i read Tarus email, i wrote in Slack to Nate Berkopec (puma maintainer): `Hi. AWS destroyed me, i'm going to take a big break .`

Then his email reset my cortisol levels to acceptable level.

Most importantly, this incident triggered a CoE (Correction of Error) process inside AWS.

That means internal systems and defaults are being reviewed, and that’s more than I expected. We’re getting a real update, that will affect cases like mine in the future.

So yeah, it may have started in the visibility layer, but what matters is that someone human got involved, and actual change is now happening.

That might be a 'lesson', but it’s like saying:

"If you want your paperwork processed in Morocco, make sure you know someone at the commune, and ideally have tea with their cousin."

Yes, it works, but it shouldn’t be the system.

What happened with AWS isn’t a clever survival tip, it’s proof that without an account manager, you are just noise in a ticket queue, unless you bring social proof or online visibility.

This should have never come down to 'who you know' or 'how loud you can go online'.

It a big luck that i'm speaking in english and have online presence, what if i was ranting in French, Arabic, or even Darija in Facebook. Tarus will have never noticed.

The AWS employee actually contacted me before my blog post even reached three digits in views. So no, it wasn’t PR-driven in the reactive sense.

But here’s what I learned from this experience: If you are stuck in a room full of deaf people, stop screaming, just open the door and go find someone who can hear you.

The 20 days of pain I went through, it wasn’t because AWS couldnt fix it.

It’s because I believed that one of the 9 support agents would eventually break script and act like a human. Or that they get monitored by another team.

Turns out, that never happened.

It took someone from outside the ticketing system to actually listen and say: Wait. This makes no sense.

The person paying the account is not the author, i'm.

What happen is that the person paying for the account had to settle an invoice of many thousand of dollars. They offered me AWS gift cards,to send me electronics and they will pay for it in parts.

They lost lot of money because of crypto collapse. So i accepted their solution to pay for my OSS usage for few months.

That like if i was going to pay for your rent for 1 year. You don't pay, while i don't have to pay 3-4 years of your rent at once.

What happen, is that AWS dropped a nuclear bomb in your house, in the middle of the month .. then tell you later that it was about payment.

If they told me in the first email it was about the payer, i will have unlinked and backuped.

Yeah, it's fishy. I never claimed the Java theory is confirmed, just that it’s what an insider told me after the fact.

They said a dry-run flag was passed in the --gnu-style form, but the internal tool expected -dry, and since Java has no native CLI parser, it just ignored it and ran for real.

Supposedly the dev team was used to Python-style CLIs, and this got through without proper testing.

The idea of a rogue AWS team running a deletion script without oversight should sound ridiculous. At a company that size of AWS, you will expect guardrails, audits, approvals.

But here is the thing: no one from AWS has given me an official explanation. Not during the 20-day support hell, not after termination, not even when I asked directly: “Does my data still exist?” Just a slow drip of templated replies, evasions, and contradictions.

An AWS insider did reach out claiming it was an internal test gone wrong, triggered by a misused --dry flag and targeting At a company that size, you'd expect guardrails, audits, approvals low-activity accounts.

According to them, the team ran it without proper approval. Maybe it is true. Maybe they were trying to warn me. Maybe its a trap to get me to throw baseless accusations and discredit myself.

I'm not presenting that theory as fact. I don’t know what happened behind the wall.

What I do know is:

- My account was terminated without following AWS’s own 90-day retention policy

- I had a valid payment method on file

- Support stonewalled every direct question for 20 days

- No answers were provided, even post-mortem

When you put a repo in Github, everybody that forked or clone that repo become a Mirror.

My post is not about backup strategy, it’s about what happens when the infrastructure itself becomes hostile, and support throw you from one team to another. AWS didn't just delete files.

They gaslit me for 20 days while violating their own stated policies.

I dont disagree with your broader point—centralizing everything in one provider is a systemic risk.

The architecture was built assuming infrastructure within AWS might fail. What I didn’t plan for was the provider itself turning hostile, skipping their own retention policy, and treating verification as a deletion trigger.

I did have backups. Multi-region. Redundant. I followed AWS’s own best practices to the letter.

The only failure I didn’t plan for? AWS becoming the failure.

The provider nuking everything in violation of their own retention policies. That’s not a backup problem, that is a provider trust problem.

The reason i did not kept a local copy, was that i formatted my computer after a hardware failure, after the nurse dropped the laptop in the hospital i was on. Since i have a AWS backup, i just started with a fresh OS while waiting to get discharged to return home and redownload everything.

When i returned 6 days days later, the backup was gone.

Not AI-generated. Not everyone is born writing flawless English.

If it sounds like an LLM, maybe it is because people like me had to learn how to write clearly from LLMs because English is not our first language.

I could’ve written in my native tongue, but then someone else will have complained that not how english is structured.

Also, the story is real. Just because it is well-structured doesn't mean it's fiction. Yes, i used AI to resort it, but i can assure you that no AI will generate the Piers Morgan reference.

Hi, The infrastructure was not complex at at all, i can transfer it in 1 day.

I was hospitalized, in another city, with all the computer at home, and locked behind 2FA.

They send me is on notice on Thursday, by Monday evening, all access was revoked.

For weeks i asked for a readonly access to my data, then they could take anytime they want to verify, they refused.

And he more i ask about my data, they more they avoid to speak about it.

Think about it , you could be sick, on a trip, having jetlag, in some festival, getting married... by the time you are back online, the delay was gone.

Same here, i used them for years.

Feel you.

No offense taken—you're absolutely right.

In fact, I even added an em dash shortcut to my Logitech POP keyboard. That’s dedication. See? — — — — —

I’m not just writing like this—I’ve industrialized it.

If it sounds like a chatbot, maybe it's because I have spent too much time training them and not enough time pretending to be a chaos monkey in HN threads.

Appreciate the feedback though.

Now excuse me while I reboot into Windows just to add and to my custom shortcuts.

I have still got one more slot—what do you think I should add?

Go wild. Bonus points if it makes someone uninstall the gem out of pure emotional confusion.

Circuit breakers are inherently bi-modal (all-or-nothing) while token buckets provide smooth pressure control like cruise control vs an on/off switch.

BreakerMachines focuses specifically on failure protection rather than rate limiting. Circuit breakers and token buckets solve different problems:

- Circuit breakers: Reactive failure protection (stop calling broken services)

- Token buckets: Proactive rate control (smooth request throttling)

They're complementary patterns. I actually have a rate limiter gem with token buckets, sliding windows, and distributed rate limiting, but I will open source it when my ship lands on a planet or a moon. Still navigating hyperspace.

Thanks for the feedback

Merci pour la remarque !

Your 2 space credits are worth their weight in dilithium.

Funny thing is the gem originally started exactly like that, pure explicit constructors. Then I wrapped it with the DSL sugar but the explicit approach never lost its capability. Both paths lead to the same destination.

I actually loved this suggestion so much that I added a whole section called "Captain Byroot's Guide to Explicit Circuit Construction" to the docs:

https://github.com/seuros/breaker_machines/blob/master/docs/....

The resistance appreciates your feedback.

I did split the readme now. Thank you again.

Appreciate the feedback—really.

You are correct to point out the mismatch on the image caption, i generated a few and copied the wrong one. That one's on me, i will update it later.

And while AI might correct a typo or help rephrase a sentence here or there (I’m not a native English speaker), everything in that README—tone, structure, content, rants, and lore—is 100% me. It's my style. Love it or leave it.

As for scaring people off ? That’s not a bug, that’s a feature. This is an open source circuit breaker, not a SaaS onboarding funnel. If someone decides not to use a well-tested library because the README isn’t sterile enough for their corporate taste, that is their loss. I'm not here trying to win two potential enterprise clients who expect a PDF pitch deck and a hug.

The circuit breaker pattern itself isn’t new, I didn't invent it, it has even its own wikipedia page. But the Ruby ecosystem? Still treating it like a nice to have.

Existing circuit breaker gems like Circuitbox, Semian, etc., are stuck in the past. They rely on patterns and syntax from the Ruby 2.6 era, and integrating them into a modern codebase often means a painful refactor or bending your architecture backwards. BreakerMachines is built for 2025, fully async, fiber-safe, and designed to work with modern Ruby without dragging a legacy ball and chain. It's don't even support version of ruby that is 1 version behind. Upgrade then use.

If someone is going to get frustrated by a long README or AI-generated images, they’re welcome to go pay someone to write them a handcrafted if/else block and call it resilience.

The code is clean. The tests are good. And if just that MD file makes them walk away from that—again, their loss. They don't even read it.

I maintain a ton of gems. And I’ll be honest: my enthusiasm for open source has been repeatedly drained by the "please make this more corporate-friendly" crowd. Not talking about you specifically—but there’s a whole wave of people who want everything politically polished and personality-free. That’s not why Ruby was created.

Ruby was made for joy. And this gem? It reflects that.

Cheers for actually reading and for giving honest feedback. You’re rare for that. Just don’t expect me to dress up like a SaaS salesperson anytime soon.

Hey HN! I extracted BreakerMachines from my apps after seeing people dealing with cascading failures in production Rails apps.

Key features that set it apart:

- True async/fiber support (works with Falcon, async gems)

- Built-in fallback mechanism with chaining

- Thread-safe without dangerous Timeout.timeout

- Memory-efficient with WeakRef tracking

- Rich introspection and monitoring hooks

- Clean DSL that works with inheritance

With everyone adding AI/LLM APIs to their apps, circuit breakers are more critical than ever.

These APIs can be slow, flaky, or have outages - without protection, your app goes down with them.

The README shows patterns for graceful degradation when a service is down.

I explicitly avoided shipping Redis/DB adapters to keep it focused, the README shows how to implement your own in ~20 lines.

Would love feedback on the API design and any edge cases I might have missed!

I'm still going to add the parallel feature, i removed it because i need to test it in CI.

Hi HN! I'm sharing COSS (Contribution Open Source Standard) addressing two big problems: vendor lock-in and AI computational waste.

  The AI angle: Current AI tools waste enormous compute re-analyzing the same project patterns. "Is this Python or Node?", "What's the build
  command?", "Where are the tests?" They hallucinate answers instead of reading structured metadata.

  COSS includes a comprehensive coss.toml format for this:
  ```toml
  name = "my-project"
  languages = ["Rust", "JavaScript", "Python"]
  project_type = "web-application"

  [frameworks]
  backend = { name = "Rails", version = "8.0.2" }
  frontend = { name = "Next.js", version = "13.2.1" }

  build = "make build"
  test = "make test"
  lint = "eslint --config .eslintrc.yaml"

  [test_frameworks]
  javascript = "jest --ci"
  rust = "cargo test --all"

  [dependency_locks]
  javascript = "yarn.lock"
  rust = "Cargo.lock"

  This helps AI tools understand your project instantly with one sweep, no more guessing at build commands or test frameworks. It covers everything from languages
  and dependencies to security scanning and documentation coverage.

  Important note: The spec is not final yet, contributions and feedback are very welcome! We want to get this right before wider adoption.

  The broader problem: Too many "open source" projects have hidden vendor dependencies or lock-in mechanisms. COSS defines 5 principles for truly
  neutral software:
  • Universal Access • Anti-Vendor Lock-in • Optional Dependencies • Modular Scope • Contributor Ethics

  It's not a license, it's a standard and mark signaling genuine openness.

  Benefits:
  • Faster, more accurate AI coding assistance
  • Reduced AI computational waste across the ecosystem
  • Protection from vendor traps
  • Better project discoverability and cataloging

  Would love HN's feedback. Do you see AI tools struggling with basic project understanding? Have you hit vendor lock-in pain points? What metadata
  fields would be most valuable?

  Template: https://www.contriboss.com/coss.v0.0.1.toml
  Discussions: https://github.com/contriboss/discussions

People hate him because he do everything to be hated.

Could be a competitor if it was not send from a reputable email domain.

What if the woke AI end his career before ?

Someone posted yesterday the rails/rails repo, and it was pretty impressive.

You should give it documentation is can't guess.

Did you read the spec ? Everything you said is already a recommendation.