that link 404's :(

What a shame.

Please check the archive for now: https://web.archive.org/web/20240628184010/https://www.sc.co...

just curious, what problems do you see with gobgp?

(I have only a rather basic familiarity with go, but was considering gobgp for an infra project...)

Not speaking to their code, but to start GoBGP has the worst performance of any BGP daemon by a large margin [1].

[1] https://elegantnetwork.github.io/posts/comparing-open-source...

Garbage collected languages like Go will always have worse performance than lower level languages like C (frr and bird are implemented in C).

Gobgp is great if you want to embed it directly into a Go app though. Talos Linux has done that recently.

Nope, it is a matter of skill as well.

https://github.com/ixy-languages/ixy-languages

No they won't. They are generally faster in throughput than any non-gc application that isn't heavily hand optimized. Their problems are higher memory usage and unpredictable latency, not speed.

Just look at the code. Anywhere you like. There's nothing I can say that will be a substitute for seeing it yourself.

I've had to use it as a library sometimes, and it's also really poorly designed as a library. There's no consistent principle for what is exported and what remains internal, so almost anything non-trivial you do may require you to copy-paste parts of the library code because something happened to not be exported. So you must think, okay sure, but in return for that you get a minimal and stable API. Nope! It also has some of the most API churn of any Go module, already up to /v4 and that's only counting the semver-major breakage they bothered to acknowledge, not the many semver papercuts along the way.

not an app per se, but pandoc is great...

I might be outing myself as a noob here, but... what is the (better) alternative?

You inject the pool itself.

Sorry, I am being dense... how does that solve the problem?

I still have to get a connection from the pool, I just do it inside the function body now, right?

So this

    @app.get("/users")
    def get_users(conn = Depends[get_db_conn]):
        users = conn.execute("SELECT * FROM users")
        return users

would become that instead:

    @app.get("/users")
    def get_users(pool = Depends[get_db_pool]):
        with pool.get_conn() as conn:
            users = conn.execute("SELECT * FROM users")
        return users

But I still need enough connections in the pool to handle all concurrent requests, no?

The idea is you only take a connection from the pool when you need to touch the DB, then you give it back immediately. It's very possible that's only a small fraction of the time spent in some handlers. If you inject the connection, you always hold it through the entire request.

No - you do not always give it back immediately in many cases as you have a transaction, which cannot "change hands". If a write connection makes consecutive updates to the DB, you must see it through before closing.

I meant you give it back immediately when you're done with it. So usually after you commit, unless you want to hold it longer for some special reasons.

ahh, gotcha! thanks!

Am I the only one seeing _crazy_ levels of CPU usage when opening the project's homepage (https://buzz.xyz)?

Like "maxing-out-8-cores"-crazy?

Yeah, crazy that a landing page exhausts the resources of my 2019 CPU. Mouse movement tells me it runs at like 5FPS.

No, me too. 758% processor usage in Firefox.

the more Tokens/CPU use the better your project. /s

NAT is a crutch to circumvent the problem of "there are not enough addresses for each device".

I _assume_ you are referring to a default deny inbound firewall (so that devices are not reachable from the outside), but these are very different, completely orthogonal concerns (and independent of the IP version in use).

Everyone I've talked to with this opinion are typically mobile devs thinking about cell phones. Ipv6 works great there, but NATs are often used in corporate networks for isolation and in particular obfuscation. You can't tell what's behind a NAT by inspecting traffic coming from inside it like you can with no NAT networks. Some of the networks I administrate are contractually obligated to be so isolated.

I am not a mobile dev :D

I am aware that NAT is often used in corporate networks, but it does not automatically make any more sense there - the isolation is achieved by the firewall, not by NAT.

NAT (address or port translation) and a firewall (allowing traffic from/to those addresses or ports) are orthogonal concepts.

You can do NAT on IPv6, if you so desire.

It _should_ make no difference whether any adversary knows "what's behind a NAT", because it is your firewalls job to block any unwanted traffic.

Relying on "nobody knows what is inside our network so it can't be attacked" is not a viable strategy.

> I administrate are contractually obligated to be so isolated

Yeah, I've seen those contracts. They just reference a SeCuRiTy doc that's 20+ years old, and has never been re-evaluated. Things are secure because they follow the doc, not because they have actually evaluated the reasonable attack space.

I've fighting customers for years on their ideas of proper TLS usage and it's always the same thing. They've got a security doc that never changes and has never evaluated any of the trade-offs. Almost to the point that the people who wrote them choose things that increase downtime and KTLO work without helping security.

Ah-yup. The equivalent in my world is contracts that insist we make our employees rotate their passwords every 2 months or whatever, which was a popular (but still dumb) idea 20 years ago and is strongly recommended against today.

Yep. I get real tired of adding a month and year to the same base password every time I need to rotate it.

On week one of my current job, I turned that off for the whole company. Here's the citation you can give your security department to show them why they're doing it wrong.

NIST Special Publication 800-63B, the July 2025 version, section 3.1.1.2, says:

"Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically. However, verifiers SHALL force a change if there is evidence that the authenticator has been compromised."

The previous version from June 2017, section 5.1.1.2, says:

"Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator."

So 9 years ago, NIST said to stop requiring that. Last year, they clarified that to say, no, really, freaking stop it. Any company still making people do that today is 9 years out of date, and 1 year out of compliance.

There isn't any reason you can't set up a NAT like that with ipv6.

I am not sure this approach can take you very far.

In my experience, CC makes it very very easy to _add_ things, resulting in much more code / features.

CC can obviously read/understand a codebase much faster than we do, but this also has a limit (how much context we can feed into it) - I think your approch is in essence a bet that future models' ability to read/understand code (size of context) improves as fast or faster than the current models' ability to create new code.

Ouch. I guess this came across as "my approach". I haven't done enough agentic coding to feel like I know enough to have a worthwhile, but at the moment I'm squarely in your camp. I don't believe it's going to work to let an agent loose expanding a teetering codebase with little to no concern for maintainability. We're going to have to painfully relearn the lessons of pre-AI coding, whatever that means with AI in the mix.

I wondered about this as well.

OTOH, consider that in the "pick the majority from 3 CPUs" approach that seems to have been used in earlier missions (as mentioned in the article) would fail the same way if two CPUs compute the same erroneous result.

While I agree in principle, as of now the latest commit to the pyaes repo and its latest release to pypi are from 2017...

So the next and final commit should be a message at the top of the README saying the library is unmaintained and contains serious vulnerabilities and users are advised to move to alternative XYZ.

Would have to be F32, no? I cannot think of any way to enforce "non-zero-ness" of the result without making it return an optional Result<NonZeroF32>, and at that point we are basically back to square one...

> Would have to be F32, no?

Generally yes. `NonZeroU32::saturating_add(self, other: u32)` is able to return `NonZeroU32` though! ( https://doc.rust-lang.org/std/num/type.NonZeroU32.html#metho... )

> I cannot think of any way to enforce "non-zero-ness" of the result without making it return an optional Result<NonZeroF32>, and at that point we are basically back to square one...

`NonZeroU32::checked_add(self, other: u32)` basically does this, although I'll note it returns an `Option` instead of a `Result` ( https://doc.rust-lang.org/std/num/type.NonZeroU32.html#metho... ), leaving you to `.map_err(...)` or otherwise handle the edge case to your heart's content. Niche, but occasionally what you want.

> `NonZeroU32::saturating_add(self, other: u32)` is able to return `NonZeroU32` though!

I was confused at first how that could work, but then I realized that of course, with _unsigned_ integers this works fine because you cannot add a negative number...

You'd still have to check for overflow, I imagine.

And there are other gotchas, for instance it seems natural to assume that NonZeroF32 * NonZeroF32 can return a NonZeroF32, but 1e-25 * 1e-25 = 0 because of underflow.