brenns10

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.

Again, go make a pull request if it matters so much to you.

> I for one will be glad if there's a platform left that hasn't been invaded by AI.

There's always Linux! ;)

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.

It sounds like you're recklessly interpreting the parameters by which your "self driving" car was made available to you

Did it also drive itself back to your home empty?

I'll believe it when they accept liability for the actions of their autonomous vehicles. Videos mean nothing.

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.

(warning: pedantic comment)

"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

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.

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

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.

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

This is a good idea for the short-term. As of now, frame pointers are the most reliable way to ensure that software can be profiled by tools like perf*. The core issue is that the kernel must be the one to unwind the userspace stack, and it only knows how to unwind stacks with frame pointers**. The .eh_frame data will never be supported by the kernel, because it involves a turing-complete program that must be executed to compute the necessary unwind info***.

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/

I just tried out the app - an SMS challenge was sent to my phone number, and the app sends a response via SMS. By challenge, I mean there's several fields with encoded data (not just a 6-digit OTP).

I have no idea how it's implemented by Apple but I'd hope there's some sort of expiry time. I'm sure they've thought of SIM-swapping as a way to take over people's accounts.

Interesting, I admit to never studying that history and only hearing the story as told by others after the fact!

I think the very defense you're using is the problem though. It's fine if nobody uses the competing browser for work at Google. It is, however, pretty standard to have automatic tests for performance and functionality, and these need to be cross-platform. Having insufficient automated testing for Firefox to catch these sorts of issues is a structural, anti-competitive bias. Especially when these things clearly don't happen with Chrome.

Couple that with the article's documented case of using a deprecated API from Chrome that's unsupported in FF. That's bias in the design, and that's something that leadership is either not catching, or making a conscious decision on. I'm sure it's couched in some statstic about which monetizable users are impacted or something. But at the end of the day it's an organizational, structural bias.

And that's not to say this is necessarily illegal. I honestly wouldn't know. But I think you made a straw man to attack. The allegation isn't necessarily that there's an organization wide conspiracy of evil Googlers. Just that the organization and culture is designed to benefit Chrome and disadvantage Firefox, and that's happening regularly with user-harming effects.

Yeah. The money is there to ensure that there's an independent browser option to point at, if there's ever any question about lack of competition. But the products are all designed to behave worse on Firefox, to help keep usage in the single digit %s.

Reminds me of Microsoft saving Apple back in the day. It's cheaper to prop up your competitors to avoid becoming a monopoly, than it is to become a monopoly and get broken up. Of course ideally, you don't want to support your competitor to the point of them actually becoming competitive, just enough to have deniability.

To quote the very article you're commenting on:

> But plug and play often means for a hardware maker: "let's do trial and error until Windows seems to behave in a correct way".

It would seem that the Microsoft way, at least in this case, would be to let the hardware manufacturer fall over themselves changing their device's behavior in order to fit however Microsoft implemented the generic drivers. No matter whether it is a correct implementation of the relevant standards.

This is quite efficient, in that Microsoft never even needs to claim there was a bug in the first place, let alone fix it ;)

Incidentally, "jaywalking" will be legal in California in 2024, finally. Hopefully that will be the beginning of the end for those laws across the rest of the country.

(Of course, we're talking about crossing "when safe", not when you'd be walking into the path of a vehicle with the right of way.)

I love and use rich too, but gosh I hope that libraries don't start depending on it just because pip does.

It has a lot of dependencies of its own, and dependency creep is real. I know pytorch isn't exactly lightweight in terms of dependencies. But I prefer using libraries that make an effort do only pull in absolutely necessary dependencies.

> So only the rich can drive and park? FWIW, my city charges £6.70/hour for parking and it's still impossible to find a spot.

I definitely understand that parking can be a major expense, but I do believe that if the cost of parking is the tipping point (and not the cost of fuel, insurance, registration, repairs/maintenance, and likely regular car payments w/ interest...), then it's a symptom of a larger problem. Car ownership is by definition expensive, and the better approach is to work on making it unnecessary for people to own a car, rather than deciding that we have to further subsidize the car and fossil fuel industry by giving away/underpricing parking.

And yes, I'm definitely sympathetic to the fact that in many places, it's just necessary to own the car in order to live life. But market priced parking is actually part of the incremental solution to change that: it is cheaper to enforce and brings in more revenue which can be directly used to solve those problems, by improving public transit and infrastructure for alternatives to cars. Or it can go to tax rebates/incentives to use these alternatives.

Two hour parking (I'm guessing it's free, but it doesn't really matter) is the result of such a mind-numbingly obvious market inefficiency. Street parking is being given away for free, or at incredibly cheap prices, so of course demand is high and drivers visiting businesses can't find spots. So the city tries to disrupt demand by placing these artificial time limits, in the hope that it will allow visitors to park more easily. The obvious answer is to just charge market rate for street parking, and there will almost always be a few spots available. And anybody willing to pay market rate for 8 hours of street parking is welcome to.

To top it off, time limits are so stupid to enforce, as you say. It's easy to enforce meters, or paid parking with plates on a block. "If paid and not in red zone, ok, else, ticket." But instead cities have to come up with these "creative" (read: broken) systems for catching people who park too long.

edit: and same applies for weekends: charge market rate then too!