There's always Linux! ;)

These people are NOT BUILDING A PRODUCT. There ARE NO USERS. No customers. No investors. No business considerations. There are just contributors, donating their time and money to a project they feel is worthwhile.

If they don't want to focus on "UX," they don't need to. If a person who believes in the project lends their time toward improving UX, they can. But it's not the job of ANYONE, contributor or maintainer, to do anything that doesn't serve the existing contributors.

And I know that sucks for welcoming new folks. I know it would be better for a project to do outreach. To try to position themselves to bring in new members. Many such projects do that. But it sure is galling to suggest that it's a project's JOB to do something more when they're providing tons of free content to you. If it mattered enough for you to comment, go work on it!

If it's full self driving, then I assume that Tesla is paying for your insurance and taking all responsibility for any crashes it causes in your car?

Did it also drive itself back to your home empty?

Ultimately it comes down to: you must trust your instance admin. (Just like you must trust Facebook and X and Tiktok and whomever else). As a result, maybe take private conversations somewhere safer, like Signal or a pgp conversation. If you don't trust your instance admin, why did you sign up with your instance?

It's like if you write a long jargon phrase and then define an abbreviation in parentheses. Next time you can use the abbreviation. If the abbreviation becomes well known enough (especially in certain groups) then you may be able to omit the definition altogether, especially if you already know your audience.

I'm not sure about schools "manufacturing their own gestures" but sign languages tend to have regional dialects and shared jargon, much spoken dialects and jargon. It could be that these signs are simply regional variations, or that a single sign hasn't become dominant.

If you enable frame pointers, you need to recompile every library your executable depends on. Otherwise, the unwind will fail at the first function that's not part of your executable. Usually library function calls (like glibc) are at the top of the stack, so for a large portion of the samples in a typical profile, you won't get any stack unwind at all.

In many (most?) cases recompiling all those libraries is just infeasible for the application developers, which is why the distro would need to do it. Developers can still choose whether to include frame pointers in their own applications (and so they can still pick up those 1-2% performance gains in their own code). But they're stuck with frame pointers enabled on all the distro provided code.

So the choice developers get to make is more along the lines of: should they use a distro with FP or without. Which is definitely not ideal, but that's life.

"et alia" is used to refer to "the others (people)" whereas "et cetera" is used to refer to "the others (things)". So you'd use "et cetera" to refer to the other posts. But if you were writing a list of authors you might end with "et al." to indicate that there are more.

I know correcting somebody's Latin usage is really pedantic even by HN's standards. I'm only saying it cause I find it interesting and want to share, not because I want to correct you :)

https://en.m.wikipedia.org/wiki/Et_cetera

But none of the current options are risk free, and I doubt this one will be. They all have risks, side effects, and probably the chance of failure. And then the question is how low of a risk is acceptable to restore a child's hearing. These are people who would live an otherwise healthy and normal life, and they'd grow up in an accepting deaf family which is likely already plugged into a community. I can't imagine how it would feel to have a serious side effect (or worse) impact your child when you know they could have gone without that procedure and lived a happy, fulfilling life. But I also understand the desire to give your child every possible opportunity.

All of that is to say, I think it is reductive to compare this to child abuse or FGM. There's no right decision, and parents absolutely will need to make a difficult choice, hopefully prioritizing their child's safety and future above all else.

If you look at the older multipath TCP implementation, prior to the upstreaming, it was intended to be fully transparent to the application, which I think makes more sense for the intent of the protocol. Sure, in many cases MPTCP may be better with application-guided logic, but having a standard system approach (e.g. establish sub-flows on an LTE connection for automatic failover, but don't send any data along those sub-flows) would have worked for 95% of cases.

[1] https://lore.kernel.org/all/alpine.OSX.2.21.1707181728570.11...

Since it can't unwind the user space stacks, the kernel has to copy the entire stack (8192 bytes by default) into the output file (perf.data) and then the perf user space program will unwind it later. It does this for each sample, which is usually hundreds of times per second, per CPU. Though it depends how you configured the collection.

That does have a significant overhead: first, runtime overhead: copying 8k bytes, hundreds of times per second, and writing it to disk, all don't come for free. You spend quite a bit of CPU time doing the memcpy operation which consumes memory bandwidth too. You also frequently need to increase the size of the perf memory buffer to accommodate all this data while it waits for user space to write it to disk. Second, disk space overhead, since the 8k stack bytes per sample are far larger than the stack trace would be. And third, it does require that you install debuginfo packages to get the DWARF info, which is usually a pain to do on production machines, and they consume a lot of disk space on their own.

Many of these overheads aren't too bad in simple cases (lower sample rates, fewer CPUs, or targeting a single task). But with larger machines with hundreds of CPUs, full system collections, and higher frequencies, the overhead can increase exponentially.

I'm not certain I know what you mean by the "slow unwinding path for perf", as there is no faster path for user space when frame pointers are disabled (except Intel LBR as outlined in the blog).

In the same spirit, it seems that the .eh_frame -> BPF unwind table process could be (relatively) easily modified to produce SFrame, which you could attach to the binaries if you have a trustworthy way of doing that (which is... a big if). So that once SFrame support becomes available in the kernel, you could apply it to applications without rebuilding them.

[1]: https://lpc.events/event/16/contributions/1361/

For the long term, the more exciting option that's emerging is SFrame[1]. This is a new data section which would be generated by the compiler and contains unwind tables which the kernel will be able to understand. Unlike DWARF/.eh_frame, these tables would remain in the final binary (i.e. not be stripped away), and on exec(), the kernel would store them for use during profiling. Since the format is quite similar to ORC(*), and Steven Rostedt is quite invested in the format, it seems a safe bet that support will land in the kernel.

My hope isn't necessarily that a distribution completely disables frame pointers once this format becomes available... though it could be an interesting thing to try. Rather, there can be a conscious choice about whether frame pointers are used, or SFrame, which would be useful for cases like Python, where it's mentioned that frame pointers may still have a significant performance impact. The kernel should be able to fall back to frame pointers when SFrame is unavailable, which means that either will be acceptable. Ideally, in a few years time we'll be able to go back to forgetting about frame pointers for most cases :)

---

* Ironically, the kernel itself tends not to use frame pointers! It has its own unwind format called ORC, which gets generated by an in-kernel program called "objtool" which essentially reverse engineers the assembly generated by the compiler. It's x86_64-specific and frequently needs adjustment when the compiler changes code generation. It can't be used for userspace programs.

** it also knows how to unwind kernel stacks with ORC (see above)

*** There is an option to allow perf to unwind with DWARF, but it's a total hack (though a very effective one). By passing --call-graph=dwarf, you can instruct the kernel to copy the userspace stack (by default, 8k bytes!) into the perf event buffer with each sample (this can be as many as 100 or 1000 samples per second, per CPU...). Later, the perf userspace program will use that info, along with information about each process's address space, and the debuginfo for each program, to unwind the stacks. This has huge performance overhead, and it requires that you have easy access to debuginfo, which may not be the case, especially for container workloads.

[1] https://lwn.net/Articles/940686/