No, they believe that almost all bugs in an operating system kernel are also likely to be security bugs. The ones which get domain names, POC exploits, and CVE assignments are the ones which were found by security researchers. But the bugs that get found and fixed by kernel developers regularly without fanfare are also very likely to be exploitable. It's just that nobody took the time to cook up an exploit chain. To kernel maintainers, it's silly to assign CVEs to just some of the likely exploitable bugs just because a security firm found them. So they decided to take the reigns and handle CVEs themselves, to ensure all potentially exploitable bugs are marked as such.
Honestly I find this quite frustrating. I really dislike when folks like yourself take your product-focused mindset into open source/public domain projects.
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!
Having used cars that had that "supervised" driving feature.... Gosh, I hope you were paying 100% attention the whole time of that driving experience you described. Even the smart cruise control features I've used allowed my mind to drift, and I was glad for the beeping from the steering wheel telling me to pay attention. I don't use those features anymore.
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?
The fact also remains that fraud (even if it's not prosecuted) is fraud. You promise X and deliver... not X, for years? You're a fraud. Even if you are getting better at delivering Y, for some value of Y which is Far, Far less than X.
Haha it definitely takes the content moderation problems and distributes then across all the instances. But that's kind of the whole point. You can join an instance that moderates content in accordance to your preferences, rather than dealing with the weird policies of Meta/X. I'm sorry you don't like it though.
What weird fake information you're posting. Yes, administrators of fediverse servers can read your personal correspondence -- same as Facebook, X, and other social media sites that don't offer federation (unless you opt into some limited e2ee option). But I, as a fediverse admin, have no ability to read (private) correspondence between two others who don't use my instance.
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?
You missed the initial part, where the signer finger spells the concept the first time they use it, and then they come up with a sign representing it. By doing so, they've shown the other person what sign they're using and its meaning.
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.
> I don't understand why frame pointers need to be in by default instead of developers enabling where needed
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.
I searched lore.kernel.org and couldn't find any postings that propose using this in the kernel. I'd encourage you to share a proposal, otherwise the "kernel team" will never be interested, because they'll never hear of it.
"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 :)
This presupposes an awful lot. If it were truly a risk free magic wand you could wave, then I could see your point.
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.
At the end of the show there are boxes to return the wristband so it can be reused/recycled. The vast majority return them, except a small portion who may keep it as a souvenir or to tear it down.
I think if you're not willing to manually verify the output of these generative machine learned algorithms, then you probably shouldn't present them to somebody as if you've done them the service of a free code review.
My understanding is that it was basically a condition enforced by the maintainers of the Linux TCP / networking subsystems. If you look at the initial upstreaming discussions[1], this was setup as a ground rule.
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.
Using DWARF is annoying with perf because the kernel doesn't support stack unwinding with DWARF, and never will. The kernel has to be the one which unwinds the user space stacks, because it is the one managing the perf counters and handling the interrupts.
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).
Yeah I saw Vaishali & Javier's presentation [1] at LPC last year! Great stuff, & certainly available to use now rather than when SFrame becomes available and supported.
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.