sbuttgereit

Hear, hear. Just because something -looks- like it has the qualities of a sequence, order, or other meaning outside of that one thing which it is: an identity, doesn't mean that you can reliably use it for that other purpose. I don't care if it's a UUIDv7 or am autoincremented-integer-of-some-sort: you're getting a record ID and nothing more. Mistaking and ID for something more is the best preparation for some poor soul's headache at some point in the (possibly distant) future.

I think the bigger lesson from what you say isn't so much about Waymo or this topic generally but to always remember that forums like HN are not reliable reporters of reality: they can only give you an indication of who was moved to say something and an indication of what they want you to believe... true or not.

I'm sure you were already aware of that, but its easy to forget that and think you're dealing with something more real.

In Git, but workflows in Jujutsu aren't necessarily the same as in Git.

Branches for example aren't named in Jujutsu. You can bookmark them which gives them a name in some sense... but that's an optional thing you can do, often as a concession to centralized Git interoperability.

So in this case the parent to your post isn't thinking about it wrong given the context and such workflows have their advantages I've found.

Perhaps... but is this all you found once you made it into the Ministry of Information? Perhaps this was a sort of Information Retrieval all its own?

Geologic systems are more complex than this. Analyzing something like this as though it were a single system is wrought with the dangers of miscalculation.

You could locally release stresses on an incremental, short term basis this way in a local system, while at the same time increasing stresses on nearby systems which could fail even more spectacularly, especially if the increasing stresses are being moved from a less dangerous system to a more dangerous system.

I'm not suggesting the above is true in this case, but that you need to cast a pretty wide net with increasingly unknown (and perhaps unknowable) variables as you start to inject real changes into a local system and try to predict what those changes will actually do.

In all honesty I think this is an unfair characterization. I've listened to his podcast for a fair number of years and I think you're exaggerating quite a bit.

Mostly the episodes are specific topics with a guest who's area of research/specialty is the topic and which stay pretty well on-topic.

Most of the AMA episodes are in the area's where Carroll specialize: physics and philosophy of science. It -occasionally- veers off into politics or basketball, but it's nowhere close to 51% politics and basketball. I think the most recent AMA did have more basketball than usual, and admittedly more than I like. And I am not a fan of his politics nor do I consider his political positions especially thoughtful or insightful. But those diversions are more occasional distractions than some majority of the AMA content. And in a 3+ hour Q&A format its not surprising that he's asked about those areas where his regular listeners know that he has a particular interest or position.

Right. The de facto/apparent case that many users encounter shouldn't be considered the correct mental model or implementation pattern... it just explains why some people see it that way.

Not long ago I designed an authentication system which had to be disconnected from authorization pretty fully. The authentication was global in a multi-tenanted system, but access to any tenant was authorized at the tenant level (as well as all other authorization concerns). To be fair, there was some global authorization concerns, but the vast majority of authorizing actions, including tenant access was governed at the tenant level after authentication.

I think you've got the right idea, though in practice the initial "authentication" question (you are who you say you are) is very closely linked to the initial "authorization" evaluation (can you enter).... because in most systems the only "can you enter" authorization required for access is in fact that you are who you say you are.

But not all systems work this way. There are some systems where you can log in successfully, but then are immediately escorted out because the "can you enter" question has secondary considerations or is decided once identity has been established based on a larger criteria. Expired accounts in some systems work exactly like this.

"Can do" and "can do easily" or "can do with minimal friction" aren't the same.

I use JJ locally and for those that call it a "porcelain" or a "git UI" are missing a lot. Sure you can use it that way, but what I've found is that it facilitates (and perhaps encourages) a pretty different workflow than I'd use with just plain Git. I could pull off what I do in JJ in just plain Git... but it wouldn't at all feel natural and you can really see this when you start using a JJ driven repository with Git tools (including just the Git command line tools).

Personally, and as a mere version control user, I prefer the JJ model of version control much more than Git's. The mechanics of the UI was very easy to get under my fingers (the essentials in about a day), but getting the ideas and really getting an understanding/appreciation for the conceptual differences and their ramifications on workflow took a month or two of regular working and trying things. For me, it was worth the effort.

Of course. But still it's not the same.

What's different is that I found the journey can be just as interesting and engaging as the destination. I read papers, books, and even spend time around here... not because the solutions require it, but because I care about the craft and the process itself.

So yes, the resulting solution is the prime mover, but the process of finding the solutions is no longer just a means to the end, it's part of the motivation of being involved in the profession at all.