alfons_foobar

What do you mean, "unknown contents"?

Just trace back the dict to it's origin, through all the places it can be modified, and you know what is (or could be) inside...

/s

That's a funny idea :)

I think the first one should be very much doable, but I am not sure how I would build the "almost complete" and the "similar colors" features.

Well yeah, Obsidian is basically a markdown editor with some nice extra features. And apparently a quite thriving plugin ecosystem.

Well yeah, in the end they are just plain text, prepended to the user input.

It makes a lot of sense for read-heavy workloads, for sure!

I was just trying to get a better understanding of what is happening under the hood :)

Soo... We have a network hop after all?

> Instead of relying on a single server to store all data, we can replicate it onto several computers. One common way of doing this is to have one server act as the primary, which will receive all write requests. Then 2 or more additional servers get all the data replicated to them. With the data in three places, the likelihood of losing data becomes very small.

Is my understanding correct, that this means you propagate writes asynchronously from the primary to the secondary servers (without waiting for an "ACK" from them for writes)?

Not even necessary, just update the DNS record pointing to your home address

That is correct, but the @runtime_checkable decorator (which goes on the class that defines the protocol, e.g. "Animal" in the blog's example) makes it so that any class that implements the required methods (e.g. Rabbit) also passes the isinstance test (so isinstance(Rabbit, Animal) does actually return True, even though Rabbit is not defined as a subclass of Animal, i.e. NOT class Rabbit(Animal) !)

Whether it makes sense to use that is a different question, but it is possible :)

See https://docs.python.org/3/library/typing.html#typing.runtime...

True.

Also this:

"Because Animal is a Protocol, any class that defines feed() becomes an Animal"

is slightly incorrect.

By default, protocols are only relevant for static type analysis, but you _can_ enable runtime instance checking using the @runtime_checkable decorator.

(So you can do "if isinstance(foo, Animal):...", but AFAIK this decorator comes with a performance penalty)

This is a good example of a game-theoretic equilibrium :)

I might be dense, but I don't understand what that has to do with type hints...

To my eyes, the problem of choosing useful defaults for complicated types/datastructures is independent of whether I add type hints for them.

I think I am missing something...

Prometheus is not agent based though

kudos for actually looking what the problem is.

As a (former) NetEng, it bothers me to no end that so many people claim "it's the network" when their application is slow / broken, without understanding the actual problem.

This.

I often use generator expressions for the intermediate values (so I don't allocate a new list for each step), but I find this to be much more readable.

> Just write:

    if key not in table:
        return default_value
    value = table[key]

I think this could/should be shortened to

    value = table.get(key, default_value)
    ...
    return value

No?

In case you disagree, I'd be happy to hear your thoughts!

I assume you're basically referring to this quote from the article?

"Ignore fields coming from the API if you don’t need them. Keep only those that you use."

IMO this addresses only one part of the problem, namely "sanitize your inputs". But if you follow this, and therefore end up with a dict whose keys are known and always the same, using something "struct-like" (dataclasses, attrs, pydantic, ...) is just SO much more ergonomic :)

> This is a lie. A "session through the NAT" does not really expose the host to the outside world, because in 99% of the cases this is a TCP session, and the NAT machine would drop all "out of order" packets.

No, it's not. NAT only translates addresses and does not inspect the TCP "internals" (like sequence number etc, which would allow it to block certain packets).

What you are describing is a stateful firewall that allows "reply packets" for an established TCP-session.

FYI, it's called "node_exporter" ;)

Glad I am not the only one feeling "weird" about the separate branches thing :D

Probably just a matter of taste, but I think having the files for different environments "side by side" makes it actually easier to compare them if needed, and you still have the full commit history for tracking changes to each environment.

> only international peering

The concepts of "national" and "international" don't map very well to the internet.

Many companies run multiple ASes, and many companies are peering at IXPs all over the world...

> Some form of cryptographic ownership verification is the logical next step to prevent these things from happening.

a.k.a RPKI

What do you mean by "privilege" in this context?

Hm, I understood "ip endpoint" to mean something else than a router (because I am very sure that Geoff is aware of the "ICMP is not handled on the ASIC"-issue).

He does ping through the starlink terminal:

> ping across a Starlink connection from the customer side terminal to the first IP end point behind the Starlink earth station

That is true for ICMP packets directed at the router itself.

Pretty sure that is the reason why he used

> ping across a Starlink connection from the customer side terminal to the first IP end point behind the Starlink earth station

instead of pinging the terminal itself.

(ICMP packets passing _through_ a router are handled just like any other traffic and are therefore OK for an analysis like this)

Ordered by insertion (see [Mailinglist](https://mail.python.org/pipermail/python-dev/2017-December/1...))

This might or might not be what you want/expect...

> rock solid principle

I see what you did there :)

On a technical level, this is very simple - just change the list of DNS root servers on all "participating" machines to point to your own new nameservers.

But then you have the problem: Who manages your community controlled domains? Who keeps track of who owns which domain?

We use poetry inside docker in a very similar way, but use a multistage docker file - the "builder" image has poetry installed and installs the application into a venv, we then copy that venv to the "prod" image and run the application there (so we do not have poetry or any other packages that are only required at build time in the final image).

Any thoughts on that approach?