Well in a sense that is true. This guy is pretending like he's the only one that sees bugs. In reality he's the only one that isn't able to understand priorities. If you're constantly reporting every bug no matter how trivial, that is a problem. You're wasting people's time.

Never is a strong word. In cases where you don't need strong cryptographic or statistical properties it's totally fine. That's 99% of cases.

Nobody is modding a single byte. You're going to have a 32-bit PRNG at least. 32-bits mod 100 is easily random enough for almost every use.

I guess it's a good thing to be aware of though.

Every core, honestly

Oh hi Claude.

Yeah these types of posts are kind of useless because you can never tell if it's just because they're giving off red flags.

What feedback did he get from interviews? Do people know you can ask for feedback?

Once the browser has discovered the issuer and knows that the user is logged in to the issuer, it is pretty confident that can provide an EVT, so it can choose to ask the user for permission. Each browser implementation is responsible for making their own judgement based on their user’s expectations, so this specification isn’t opinionated about how the interface with the user materializes.

Google has likely chosen to make the permission prompt a one-time thing, which seems fine to me.

However, at that point, the website can in fact check if you’re logged in to a specific email address automatically.

It cannot.

I suspect Google would prefer a zero-click solution for their browser.

You have to put in your email address and click a button still. There's a video demo of this in TFA. There's no way they've been dumb enough to let websites figure out your email address automatically, come on.

your browser accessing your inbox

Accessing your email via your web browser is literally how 99.99% of people use email. There's nothing dubious about it.

I get that you have a gut fear about it though.

Seems reasonable to me. What are you imagining will go wrong?

Docs rarely give you information about anything except the happy path. StackOverflow did.

He's right. I think it was really a mistake for RISC-V to support it at all, and any RISC-V CPU that implements it is badly designed.

This is the kind of silly stuff that just makes RISC-V look bad.

Couldn't agree more. RISC-V even allows configurable endianness (bi-endian). You can have Machine mode little endian, supervisor mode big endian, and user mode little endian, and you can change that at any time. Software can flip its endianness on the fly. And don't forget that instruction fetch ignores this and is always little endian.

Btw the ISA manual did originally have a justification for having big endian but it seem to have been removed:

We originally chose little-endian byte ordering for the RISC-V memory system because little-endian systems are currently dominant commercially (all x86 systems; iOS, Android, and Windows for ARM). A minor point is that we have also found little-endian memory systems to be more natural for hardware designers. However, certain application areas, such as IP networking, operate on big-endian data structures, and certain legacy code bases have been built assuming big-endian processors, so we have defined big-endian and bi-endian variants of RISC-V.

This is a really bad justification. The cost of defining an optional big/bi-endian mode is not zero, even if nobody ever implements it (as far as I know they haven't). It's extra work in the specification (how does this interact with big endian?) in verification (does your model support big endian?) etc.

Linux should absolutely not implement this.

His point could be valid, if C was working fine and Rust didn't fix it. But C isn't working fine and Rust is the first actual solution we've ever had.

He's just an old man saying we can't have cars on the road because they'll scare the horses.

Ok after reading the article this is bullshit. It's only because they are counting JavaScript and Typescript separately.

Actual blog post.

Great accomplishment. I think we all knew it must happen like this but it's great to see real world results.

I think this is probably actually the most useful part of the post:

Increasing productivity: Safe Coding improves code correctness and developer productivity by shifting bug finding further left, before the code is even checked in. We see this shift showing up in important metrics such as rollback rates (emergency code revert due to an unanticipated bug). The Android team has observed that the rollback rate of Rust changes is less than half that of C++.

I think anyone writing Rust knows this but it's quite hard to convince non-Rust developers that you will write fewer bugs in general (not just memory safety bugs) with Rust than with C++. It's great to have a solid number to point to.