Not picking on you but your answer prove the parent comment's point. Your answer is that of someone that googled some answer and went with it. This problem belongs to selection algorithms and quickselect is the common approach.
> Never underestimate developing countries' governments' willingness to absolutely bend their people over to extract tax revenue (and then their corrupt representatives extract bribes on top of it)
being a developing country or not is orthogonal to what you have described. The top developed nations have one or more of these issues.
This is false equivalence. You're describing the luxury market, a vertical that is built on decoupling the raw material cost from the price tag. And in reality it is more nuanced than just raw material as there is a lot of cost in r&d/marketing/operations etc. Nevertheless, products targeted to general consumers are much more sensitive to that deviation.
Reading your parent comment and the responses, I feel be missing the point others are trying to make. There's much less technology, components, and material in a headphone compared to laptops. The circuitry in the headphones is closer in complexity to a charger than a laptop.
That doesn't sound accurate. The T in TPM stands for trust, the whole standard is about verifying and establishing trust between entities. The standard is designed with the assumption that anyone can bring in their scope and probe the ports. This is one of several reasons why the standard defines endorsement keys(EK).
I will start sharing them moving forward. I've had several parent threads deleted in the past(rightfully so) because it turned out I was responding to AI. Thank you for staying on top of this.
This is not a special case. Everything you mentioned above can actually be achieved using cli. You can create listeners, configure pipelines, and sinks(granted not ergonomic). Sinks can be HTTP post for example, and sources can be tcp listeners + protocols on top. You can also configure the buffering strategies for each pipeline.
I feel HN comments have been getting hijacked for a long time now by LLM agents. Always so early, very positive, and hard to spot. Some replaced em-dash with --, some replace them with a single dash, some remove them all together. I wonder how much time it is taking from @dang and other moderators helping to maintain this community.
Totally. I always found joy solving critical performance problems because it naturally pave a path forward to peel the layers and untangle the system interactions which feeds my curiosity, and is highly rewarding.
agreed. Strong emphasis on "profiling and identifying the actual bottleneck". Every benchmark will show a nested stack of performance offenders, but a solid interpretation requires a much deeper understanding of systems in general. My biggest aha moment yrs ago was when I realized that removing the function I was trying to optimize will still result in a benchmark output that shows top offenders and without going into too many details that minor perspective shift ended up paying dividends as it helped me rebuild my perspective on what benchmarks tell us.
Yes definitely not dismissing the lock overhead, but I wanted to bring attention to the implicit false equivalence made in the post. That said, I am surprised the lock check was showing up and not the logging/formatting functions.
a real human. threads can exist before main() starts. for example, you can include another tu which happens to launch a thread and call instance(). Singletons used to be a headache before C++11 and it was common(maybe still is) to see macros in projects that expand to a singleton class definition to avoid common pitfalls.
The performance observation is real but the two approaches are not equivalent, and the article doesn't mention what you're actually trading away, which is the part that matters.
The C++11 threadsafety guarantee on static initialization is explicitly scoped to block local statics. That's not an implementation detail, that's the guarantee.
The __cxa_guard_acquire/release machinery in the assembly is the standard fulfilling that contract. Move to a private static data member and you're outside that guarantee entirely. You've quietly handed that responsibility back to yourself.
Then there's the static initialization order fiasco, which is the whole reason the meyers singleton with a local static became canonical. Block local static initializes on first use, lazily, deterministically, thread safely. A static data member initializes at startup in an order that is undefined across translation units. If anything touches Instance() during its own static initialization from a different TU, you're in UB territory. The article doesn't mention this.
Real world singleton designs also need: deferred/configuration-driven initialization, optional instantiation, state recycling, controlled teardown. A block local static keeps those doors open. A static data member initializes unconditionally at startup, you've lost lazy-init, you've lost the option to not initialize it, and configuration based instantiation becomes awkward by design.
Honestly, if you're bottlenecking on singleton access, that's design smell worth addressing, not the guard variable.
no offense but it looks like the reason behind oauth confusion is the author. I had to read half way through to get to a definition which was a poor explanation. Sometimes certain topics are difficult to understand because the initial person behind it wasn't good at communicating the information.
Github: http://github.com/halayli/
Hydrolix Inc founder/co-founder