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.
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.
Maybe all of the stars, forks, and discussions on the GitHub page are from fake accounts
All 9k stars, 10k PRs, 400 forks & professional web site are fake? Come on this is about the most obviously not fake project I've seen!
How do you know when a product like this can be trusted?
The same way you tell if anything can be trusted - you look at the signals and see if they are suss. In this case:
The amount of effort it would take to fake this for very little benefit is enormous.
Maybe I’m just being paranoid.
Yeah just a little!
Seems a bit clickbaity to me. It's a flaw in Windows/cmd.exe, not Rust. Rust is just called out because it tries to emulated proper argument passing on Windows (and didn't get it perfectly right). All languages are affected by this but most of them just throw their hands in the air and say "you're on your own":
It's also extremely unlikely that you'd be running a bat script with untrusted arguments on Windows.
Oh hi Claude.