It's strange. Clearly at some point society at large came to believe that the current crop of terms at the time was undesirable. Yet various modern analogues are treated differently.
If you replaced "males" in that sentence with ... well, let's be honest here, pretty much any other category, the statement would likely be deemed entirely unacceptable and the comment censored (ie [flagged][dead]) in short order.
Regardless of how the statistics for that specific set of behaviors break down my personal experience is that both the application and acceptance of such terminology (ie referring to various sets of behaviors which it might make sense to group together based on whatever metric) is highly selective in a manner that's convenient for the party expressing it. The statement is often true but the grouping superfluous, included only (seemingly) to push an agenda.
It's not just pop stoicism. For years now it seems to me that a lot of memes regarding personal conduct spread on social media that essentially try to dress up toxic behavior in a positive light and encourage it.
I'm aware that society had these same sorts of issues prior to social media but it's still depressing watching it play out.
By convention they're supposed to DHCP you at least a /64 if not something wider. I don't believe there's any expectation it be static (although it typically is AFAIK) and there are some providers that defy expectations by handing out narrower slices (up to and including /128).
I realize it's intended to be an unsupported edge case but I'm curious. What happens in the event a NAT is present along the IPv6 network path? Do you just forward a port the same as you would with the various IPv4 solutions and move on? Or does it break catastrophically? Something else?
While a situation like that is really annoying, I bet it's still generally following the rule of one /64 per network. What you're not getting is control over your IPs on that network.
It is more than convention, the /64 is the minimum allocation to support SLAAC. If you're getting less than a /64 you're not getting full support for IPv6.
Well you're not getting support for SLAAC but I didn't understand that to be a core requirement to qualify as a functional IPv6 implementation.
Regardless, my point is that allocations narrower than /64 exist in the wild for better or worse. So do IPv6 NAT implementations for that matter. If you assume either of those things don't exist then you might be in for a surprise.
Aren't you describing trade secrets? I don't see how AI makes that any better or worse. If your competitor gets his hands on your proprietary dataset you're sunk regardless of AI, right?
I don't see how copyright enters into it. I doubt that "oh hey I published this very valuable and proprietary dataset online but it's copyright me so pretty please don't use it to make money" was ever going to get you anywhere to begin with.
You omitted the merge commit. M is taken so let's go with R. You jump back to M to confirm that the symptoms really don't predate the marriage. Then you jump to R to reproduce and track down the underlying cause of the bad interaction.
Had you simply rebased you would have lost the ability to separate the initial working implementation of D from the modifications required to reconcile it with M (and possibly others that predate it). At least, unless you still happen to have a copy of your pre-rebase history lying around but I prefer not to depend on happenstance.
> Had you simply rebased you would have lost the ability to separate the initial working implementation of D from the modifications required to reconcile it with M
I'd say: cleaning that up is an advantage. Why keep that around? It wouldn't be necessary if there was no update on the main branch in the meantime. With rebase you just pretend you started working after that update on main.
For the reason I stated that you quoted right there. Separating the potentially quite large set of changes of the initial (properly working) feature from the (hopefully not too large) set of changes reconciling that feature with the other (apparently incompatible in this example) feature. It provides yet another option for filtering the irrelevant from the relevant thus could prove quite useful at times.
Recall that the entire premise is that there's a bug (the allergy). So at some point a while back something went wrong and the developer didn't notice. Our goal is to pick up the pieces in this not-so-ideal situation.
What's the advantage of "cleaning up" here? Why pretend anything? In this context there shouldn't be a noticeable downside to having a few extra kilobytes of data hanging around. If you feel compelled to "clean up" in this scenario I'd argue that's a sign you should be refactoring your tools to be more ergonomic.
It might be worthwhile to consider the question, why have history in the first place? Why not periodically GC anything other than the N most recent commits behind the head of each branch and tag?
It's strange. Clearly at some point society at large came to believe that the current crop of terms at the time was undesirable. Yet various modern analogues are treated differently.
reply