It seems like the only reason Gemini knows this is because of the exact article we're discussing. Seeing as it's the first result when you search it, Gemini is just summarizing the article rather than synthesizing the info itself.
Gemini doesn't know anything. All of its outputs are synthesized via pattern matching of the prompt against its training data. No one knows exactly what the sources of any given LLM synthesis are. If one asks for a summary of a specific article then it will do that, but that wasn't the prompt.
I interpreted it as a visual cue to remind you where you left off when you return to the page after following a link. It's not particularly slick and doesn't seem to always work right. But I appreciated the novelty, effort, and creativity in trying to solve that problem.
Suni and Butch have been on the ground since March, but the article mentions that "Stranded NASA astronauts Sunita Williams and Butch Wilmore have been living aboard the ISS for 170 days since their departure from Earth on June 5."
They'll probably agree on a settlement where they don't admit any wrongdoing and give him a decent payout, but require him to take down the site and sign an NDA or something. So they don't necessarily need to replace all of them after that
If all he wants is a refund, that should do it. But if he's more interested in warning the world, hopefully he sticks to his guns and makes them give a straight up refund
Great point about accessibility. We're definitely committed to making Prepin inclusive for all users. TDD support is one option, and we're also exploring text-based interview modes and real-time transcription features. The goal is to ensure everyone can practice and improve their interview skills regardless of hearing ability. Thanks for bringing this up - accessibility should be built in from the start, not an afterthought.
If you can figure out a way to do without the nasal cannula, the possibilities are huge. Maybe a good IR camera could look at the air coming out of your nose and determine the velocity. Seems like it's actually already a thing [1].
Cynically, you could use it for surveillance, similar to how they do face recognition or temperature scanning in airports.
The flip side of the coin is that it could be used for better authentication or medical purposes. Maybe your oxygen tank could realize you're breathing different than usual to warn you that you might be having a seizure, stroke, or heart attack. Or maybe we'd have "breathe to sign in" similar to FaceID
Here's another related one that always bothers me: When you say something's loudness in decibels, you also need to specify a measurement distance.
The author of this article even accidentally makes this omission:
> It’s 94 dB, roughly the loudness of a gas-powered lawnmower
And that distance is very important; the actual sound pressure measured is proportional to distance^2. So for a lawnmower measuring 94dB, let's say we assume that we're measuring at 1m. At 2m away, the sound is actually 91dB.
And don't get me started about the fact that a halving in power is 3dB, that's just wacky. I wish we used base 2.
> And that distance is very important; the actual sound pressure measured is proportional to distance^2.
While we're sniping nerds, the inverse square law only applies in the far field (which is tautologically "far enough away for the source to behave as a point source and follow the inverse square law"). That's probably a good bit further than 1m for a lawnmower in the physical world. For loudpseakers you have to be about 2m away before the inverse square law kicks in, unless they've been designed to operate as line sources which decay linearly for a very long distance. For loud sound sources near barriers like the ground they behave like half point sources, which will eventually act like point sources but there's a good bit of distance before it is really measurable.
As far as I can tell, the reason why any given login is needlessly complex is that some product manager somewhere has outdated info in their head that says stuff like "passwords need 4 different character classes" and "everybody uses SMS for 2FA, we need to use that". Powerless devs then mindlessly implement what they're asked to implement.
Powerless, that's exactly it. I pushed back when asked to implement email-based "2FA" on a website account (nothing like as important as a bank though). I pointed out that the username is the email address, and password recovery works by emailing a reset link, therefore emailing a login code wouldn't be two-factor, it would be the same factor. Of course the response was: doesn't matter, the client's asked for it. I didn't have the authority to push back any more, but luckily in this case it was just a simple website login that had no real need for 2FA anyway.
Are you me? I am an SE in a bank and I had this exact experience this week - though it relates to authing with the online banking system.
As I see it, it's an unfortunate combination of an extremely risk-averse environment, a total lack of trust in their IT staff, and - if I can be pointed - unqualified product teams. I can explain the the inadvertent drop from 2FA to 1FA, I can back it up with NIST, OWASP and Gov references explaining why it's a bad idea, but I am simply ignored because they are bent on execution of their 'vision'. At this point, I raise my concerns just to have my biases confirmed.
It's really frustrating and obviously as a banking customer I want sensible security features too, but if I can generalise, we devs are not driving the bus. We're stuffed in the luggage compartment, wheeled out as necessary.
reply