Clocks show the time that is _passed/past_, that's the point. Hence flooring is correct approach.
Even when you involve physics, you are seeing the nanosecond past. Not the actual time. (The time that takes light to travel from clock to your eyes, then your brain's processing delay via neurons etc.)
Even the thought of being late is the same way. If something starts at 13:00 and you are not already there when it is 13:00:00.000, you are -by definition- late.
Good point, when you look at your watch your thought should be “3:15 has passed” or “3:15:40 has passed”. One is more precise but if you think of it as a time that has already passed you can budget accordingly. 3:15 tells you that 3:15:00 has definitely passed and as much as 3:15:59 might have passed.
I can see how you might suspect that, but I got a different read from it. The constant references to the topic as the "IPv6 Cat" struck me as another in the long tradition of authors who became too attached to a clumsy and ineffective analogy they thought was good enough™ and banged it like a drum. That strikes me as an all-too-human thing to do (especially since I've been guilty of it myself before) rather than an AI artifact. I enjoyed the piece nevertheless, and I agree with its premise that market forces are not enough to continue the trend of IPv6 penetration growth and that public policy carrots and sticks are both needed and justifiable to ensure it comes to pass.
On another matter, whose brainchild is IPv6+? I haven't heard of that one before.
Look at these formulations: "Respecting these governance frameworks is crucial to maintaining the open, collaborative model that underpins global Internet development and its technological evolution ... collaborative approaches that engage technical communities, promote open standards, and prioritise interoperability are essential... To overcome these challenges, a strategic approach combining economic and operational incentives with collaborative governance is essential. Governments and organisations must take proactive steps to create a more supportive environment...
By combining these measures, enterprises and network operators can address the barriers to IPv6 adoption while fostering collaboration between governments, industry leaders, and the technical community. This approach ensures that the transition to IPv6 remains inclusive, efficient, and aligned with the Internet’s principles of openness and innovation."
How is that gibberish? It's clearly a policy paper/article, and the wording is very in-line with that: it's wordy, but there's nothing factually wrong or outlandish in it.
that's honestly a leak of internal details lol. (leaky abstractions)
because internally most apps are using the coral framework, which is kind of old, using this json format as it has a well defined shape for inputs, outputs, and errors.
to be honest I saw PIP status more political reasons than actual performance reasons. In fact, one of the people I coached during focus and completed every single item still put under PIP and forced to leave.
Since then, I do not believe people got into these willingly or unwillingly, eg: due to real performance reasons. Strictly speaking on the performance or technical work wise, not company decision driven…
Even in the example above, due to the management decision, employee performance suffers. It is not up to the employee; that they do not perform by their choice.
This is not specific to open telemetry collector but overall in terms of distributed tracing, due to the nature of things it is getting extremely complicated. Especially in the Kubernetes context.
Another remark is that blog posts and tutorials include configuration not recommended for prod usage. ( in this case grpc SSL insecure option ) These quickly become foot-guns living in production
Moreover, due to the nature of go applications' static compilation mindset each component include various plugins hence their configuration quickly becoming a large file nobody except DevOps understands or configures.
Obviously original documentation is sufficient and explains well enough but nobody reads these fully. I have came across multiple times that engineers “made it work” using external service names and whatnot. Soon enough the production may hit by increasingly high response times due to both infrastructure level and tracing level misconfigurations.
I went a bit off topic and ranting here but open telemetry is a quite large piece thus should be taken carefully while implementing on a live platform.
Even when you involve physics, you are seeing the nanosecond past. Not the actual time. (The time that takes light to travel from clock to your eyes, then your brain's processing delay via neurons etc.)
Even the thought of being late is the same way. If something starts at 13:00 and you are not already there when it is 13:00:00.000, you are -by definition- late.
reply