erydo's comments

Not to imply any specific doubts—I’m aware of the narratives—but if you have references, I’m interested! Request, request.

This view is over-simplistic. Many—perhaps most—products are designed to serve more than one kind of user.

Obvious example: building an e-commerce platform. The merchant is a kind of user. The customer is a different kind of user on that same platform. Yes, they're humans, but they're not doing the same thing.

Any B2B or B2C type product will have at least two very distinct roles like that. And in those cases, arguing that everyone is just a person as a sort of moral position is destructively vague. It's more difficult to serve someone's needs if you can't start to narrow down what they're trying to accomplish.

While I totally agree with the sentiment that we shouldn't conflate personhood identically with their role in a product, solving useful problems does require that you de-scope and discretize the interactions a bit.

Congrats to the team. Though in the inevitable acquisition, I wish GitHub/Microsoft had been the acquirer: there are a lot of natural fits between that ecosystem and Keybase's model, and a reasonable history of successful acquisition.

Hopefully Zoom avoids gutting Keybase. I found it really useful for bootstrapping credentials when onboarding remote team members and contractors. Way easier to manage than GPG: it was fairly painless even for non-technical people.

Fingers crossed. I wonder what the infrastructure overhead cost is?

At some level I agree with your sentiment about shibboleth-style filtering. Not having seen these specific "tests" though, I can charitably imagine these being relevant to fault-tolerance/managed intricacy. Things like, "This code failed. How did it get to that state?" or "X can be interrupted at any time. Implement Y such that it atomically…" are examples of coding challenges that _are_ relevant to being fluent in embedded software development. I really doubt they're asking "implement quicksort"-type questions.

I care a bit. It's misleading by the standards of anyone who's used to reading graphs. Wikipedia is an organization I care about and trust and it sucks to skim a graph and realize that the axis was changed to mean something that the shape didn't convey. The entire value of graphs is using shapes to convey meaning.

That's true but still doesn't map here. Or at least, to my interpretation of it.

Stock-picking is specifically referring to where you should allocate a given amount if you are investing. There's obviously more to stocks than simply picking them, but as for picking specifically, there's no analog in poker because you don't divide your bet that way. (Aside from raising on a bluff, but that's stretching it).

Whether, when, and how much you should invest is a separate strategy that's related to your confidence and expected return of the picking strategy—but not the same thing.

Just like whether and when you agree to a game of chess vs tic-tac-toe might depend on your confidence in your skills; but that decision is _not_ relevant to chess strategy, which assumes you're already playing the game.

I believe the strategy comparison here is based on how to best allocate $X in the stock market.

Choosing not to allocate it is kind of irrelevant, just like "play tic-tac-toe instead" is not a chess strategy.

It's still just one definition: A paper map relates a point on a the piece of paper to a point in some other space (topography, subway stops, interstate routes, etc). And if you relax the "carto" part of "cartography" (e.g. someone working on OSM or Google Maps is still doing cartography), then I think cartography as "the practice of constructing maps" is still an unambiguous and non-overloaded meaning, which applies to mapping infrastructure just as well.

But, words are just words.

Mapping one's infrastructure is pretty common parlance. It's not even a pun, really.

I am even more of a layman than most here, but — why is it different? Isn't that basically Schrödinger's cat?

> There's a massive rift between "sun makes tree grow, preventing other trees from getting the light" and "I'm trying to sell my wares by expressing concepts of value, numbers, and desire".

Like a tree bearing bright red, juicy-looking fruits filled with sugar and vitamins?

Yes — won once, and died another time on the Plane of Fire. (I meant to zap down, not at myself! Damn. Learned to think before acting. NetHack is not as real-time as it feels when you're in a sticky situation.)

Just use the word that means the thing that you're talking about, as clearly as you can. What "clear" means depends on the context and audience.

It sounds like you probably already know this, but "fixed" and "constant" usually refer to concepts very distinct from "immutable". And "contextual function" would confuse everyone. (A monad isn't a function, and certainly not one influenced by some outer context). Similarly, "orthogonal" and "unrelated" aren't synonyms. (X and Y axes are orthogonal, but they're often related. That's why we plot things).

In every field, there will be people who over-use technical terms for status signaling. But those terms usually exist for a reason beyond that, and avoiding them as a sort of counter-signaling doesn't help anyone. It's just playing the other side of that game.

Usually the common term means the same things as a lot of things…that's both why they're common, and why they're less useful in a technical context.

Some other examples that come to mind are "electricity" (current, voltage, power…?); "size" (area, volume, mass…?). Just because an engineer or physicist might talk about volume doesn't mean you have to be a physicist to talk about it too. It also doesn't mean that, not being a physicist, the familiar word "size" means the same thing they're talking about.

Hey, this is really cool! Cross-language validation of data types is such a pain. This looks really well-done.

As a devil's…inquisitor, I guess— I'm curious what the reasoning has been behind the Navy's (and WWII RAF's) preference for split/seniority control and in what situations that balances out, if any. Are those situations where some known, serious risk of error is mitigated by sharing responsibility? Is betting on experience over skill actually wrong, or is their implementation misguided? Or just not applicable to those situations? (Fast situational awareness, etc)

It seems similar to the whole democracy v. autocracy tradeoff. One optimizing for coverage of perspective, the other optimizing for efficiency of a perspective.

Thank you!

What "nasty tactic" are you referring to? I see:

  Actually I was going to suggest that we work together and merge the best features of both into a common source-base that could be used by both groups going forward: eventually unifying the developer pool and mind share.  This might be difficult, but I think the end result would be useful.

Reaching out to another project with similar goals to clarify and understand the differences, and offer collaboration doesn't seem nasty. Am I missing something?

This is a really interesting topic that I know little about. This paper was published 36 years ago—is it still current with modern understanding of sailing? Or has anything changed or been refined significantly since?

Devil's advocate: Wouldn't a person who prefers sitting be more likely to keep a job as a driver rather than conductor?

An unhealthy person might think, "Ugh, I'd have to be on my feet all day." And a healthy person may not see that as a major negative.

At first I agreed with you, but realized that my preferred solution was essentially what they recommended and just with different wording. My thought process was:

  - Absolutely, DNS resolvers should not care or have knowledge of the protocol that will be used to access that address.
  - What they *should* do is just say that normal DNS resolvers shouldn't ever resolve .onion addresses.
  - (And then Tor should include a special DNS resolver that does anyway.)
  - Oh, that's compatible with what they said.

I think some of the confusion comes from their use of "applications".