151 karma · joined November 30, 2022
Yeah I was very confused by this as well.
But then again, I think/hope that anyone relying on DNS / DNSSEC for security-related $THINGS is _probably_ running their own validating resolver.
(I have only a rather basic familiarity with go, but was considering gobgp for an infra project...)
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
@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
Like "maxing-out-8-cores"-crazy?
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 _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).
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.
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.
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...
Maybe some kind of auto-formatter?
On the other hand I often see functions like you describe - something has to be executed step-by-step (and the functionality is only used there) - where I _whish_ it was split up into separate functions, so we could have meaningful tests for each step, not only for the "whole thing".
Maybe I am just a bit burned by this particular example I ran into (where this pattern should IMO not have been used).
class Foo:
def __init__(self, bar):
self.bar = bar
class Bar:
def __init__(self, foo):
self.foo = foo
So my suggestion: Try not to have interdependent classes :D
On the other hand, I tend to take it as a hint that I should look at my module structure, and see if I can avoid the cyclic import (even if before adding type hints there was no error, there still already was a "semantic dependency"...)
I think _technically_ there is no difference - it does not matter if the worst-case-behavior is triggered by an "adversary" or by chance.
It _does_ give a different mental model though.
(Also almost swallowed my tongue saying that out loud)
Also, dataclasses feels more straightforward and less "magic" to me (in the sense that it is more or less "just" a way to avoid boilerplate for class definition, while pydantic does way more "magic" stuff like de-/serialization and validation, and adding numerous methods and attributes to the classes).