bc569a80a344f9c

In your cake shop example, the more accurate version would be some gay couples only agreeing to buy wedding cakes from cake shops with gay bakers.

On account of it's the customer choosing the service provider, albeit with the help of filters provided by an aggregator, instead of service providers denying service to customers based on their belonging to a class.

edit: I missed that you can, as a woman driver, also filter out male riders.

I prefer my MacBook, but the Thinkpad whatever I bought to have Windows and Linux available for some software I need occasionally has a fingerprint reader that worked out of the box on Ubuntu.

From what I understand, it depends on the stage. The United States Code certainly tracks any and all amendments, and you can fully trace which member introduced which amendment, when and where it passed, and even verbatim floor debate.

However, the draft stage isn't documented this way. Members negotiate whatever between themselves (well, really their staffers) and this happens over email, in discussions, via Word documents - whatever works.

I guess in the git metaphor, drafts are in flux while being worked on as a commit, and are squashed and then accessible as such squashed commits once initially introduced or whenever they lead to bill amendments. You can't necessarily track down what member was responsible for a specific sentence in an amendment.

I adore Canticle. It is one of my favorite books.

I had recommended Hyperion to a friend, and they loved it. I recommended Canticle as a follow-up and they hated it. I never figured out how that can be.

The shit people tell you about themselves for free, unprompted. It’s unreal.

Kind of but not really.

The whole point of BGP is to influence your routing tables. This fundamentally makes very little sense to do when you have a bunch of routers whose routing policy you don't control between you and whoever you're speaking BGP to. eBGP is just TCP and supports knobs to run over multiple hops (so up to 255), but at that point you can't really do anything with the routing information you exchange because the moment you hand the traffic off, the other party can do with it how it pleases. Also, very few people have enough public IP addresses for this, and on the Internet you obviously can't route RFC1918 space. Therefore, you need tunnels, so that you can be one hop away even if the tunneled traffic is traversing the Internet, and so that you can reach peers that let you announce whatever IP space you want.

The other thing you can do, of course, is to just do the same thing internal to your lab. You can absolutely stand up multiple ASN at home. I'd even argue that if you really want to learn BGP, this is a great way to do it, especially if you use two different platforms (say, FRR on FreeBSD peering with a cheap Mikrotik running RouterOS). That way you learn the underlying protocol and not a specific implementation, which is something that is very hard to undo in junior network engineers that have only ever been exposed to one way of doing things.

That's different from some of the goals outlined in the article, but if your goal is to learn this stuff rather than have provider-independent IP space (which even for home labs isn't very valuable to most people), doing it all yourself works fine.

Even if yawning in public affected sexual fitness: how long has it been socially impolite to yawn in public? Evolution takes a rather long time in species with long reproductive cycles. Almost all mammals yawn, it would take significant genetic changes to breed that out of us. That doesn't happen overnight.

> it would be just nice to quickly change (or even better: have access to multiple at once!) networks.

Accessing multiple corporate networks simultaneously from the same endpoint violates all sorts of access policies. If it doesn’t, the access policy is lacking. Even for startups.

And no, unless you build it and enforce it from the start, no one ever succeeds in bolting on a reasonably security posture after implementing all their other processes no one will dare touch.

It's fine if all you need is a packet filter, but in 2026 I question that many production use cases can get away with just packet filter.

As a host firewall, it's obviously fine, I assume your question is about using pf as a network firewall. Given the threat landscape, you usually want threat protection. At the very least that means close-to-real-time updates from reputation lists. You can script that with pf, but it's not fun. Really, you want protocol dissection and - quite possibly - the ability to decrypt on the box and do payload analysis. Just doing packet filtering doesn't buy you all that much anymore these days, and anything production that requires compliance or that you genuinely care about should be behind what you might also call IPS or layer 7 firewall capabilities.

pf doesn't do any of that. You don't have to use Palo Alto or Cisco for this, either.

If all you need is packet filtering, it's a good option, though.

That’s a great way of explaining why this was historically done.

> The previous diagram absolutely does not have positive and negative for each transaction!

But it does. The $500 transaction for furniture is an edge from the bank to the furniture asset account. This edge is outgoing from the bank account (-$500) and incoming to the furniture asset account (+$500). That’s it, that’s double entry bookkeeping. Each edge represents both entries.

IP addresses in both protocols are just a sequence of bits. Combined with a subnet mask (or prefix length, the more modern term for the same concept) they divide into a network portion and a host portion. The former tells you what network the host is on, the latter uniquely identifies the host on that network. This is exactly the same for both protocols.

Or what do you mean by “parts of an IPv4 address and their meaning”?

That multicast on IPv4 isn’t used as much is irrelevant. It functions the same way in both protocols.