583 karma · joined October 19, 2012
I agree with you 100%, although I will say that it seems like newer OSes (perhaps it depends on the desktop + mobile combination, or maybe Chrome + Android is enough, not sure) have a way for you to use a passkey from your phone by scanning a QR code. I still think it's not super user-friendly but it is a clever workaround at least. Most people are accustomed to scanning QR codes, so scanning a QR code from your phone to sign in seems like not too big of a leap. (Although I wonder if it conditions users to scan random QR codes to sign in which could be a bigger phishing problem lol...).
I don't think they were being serious.
(I mean, I have no idea how Coursera/edX/etc are doing behind the scenes, but it doesn't seem like people talk about them the way they used to ~10 years ago.)
### 1. Is my code, including prompts and answers, used to train Google's models?
This depends entirely on the type of auth method you use.
- *Auth method 1:* Yes. When you use your personal Google account, the Gemini Code Assist Privacy Notice for Individuals applies. Under this notice, your *prompts, answers, and related code are collected* and may be used to improve Google's products, which includes model training.
### 2. What are "Usage Statistics" and what does the opt-out control?
The "Usage Statistics" setting is the single control for all optional data collection in the Gemini CLI. The data it collects depends on your account type:
- *Auth method 1:* When enabled, this setting allows Google to collect both anonymous telemetry (like commands run and performance metrics) and *your prompts and answers* for model improvement.
Does this mean that for a personal account, your data is always "collected", but the opt out may prevent your data from being used for training? Also, the question was about "code", but this addresses only addresses "prompts and answers". Is code covered under prompts? The first FAQ lists "*prompts, answers, and related code are collected*" as separate items so it's still not clear what happens to code and if there's a way to opt out from your code being used for model training IMO.
I am not an expert but I think in general systemd has a lot of complexity but it's to handle existing issues in a better way. Some of the older init systems might be simpler to describe or get started but lead to more confusing situations in the long run.
Gradescope is an online grading and assessment platform that uses cutting-edge technology and features like flexible autograders and AI-assisted answer grouping to make grading easier, faster, and more equitable. We're a small, collaborative team who are passionate about improving assessment in higher education. We care deeply about our users and work proactively to deliver new value for them. We iterate often, wear multiple hats, and take pride in building reliable, high-quality software. Gradescope was founded in 2014 at UC Berkeley and joined Turnitin, a leading provider of educational technology for academic integrity, in 2018.
We're looking for experienced Ruby on Rails developers to join us in expanding and scaling Gradescope:
- Software Engineer, Full Stack: https://smrtr.io/3-GGh
- Software Engineer, Growth: https://smrtr.io/424VR
(I still have yet to actually use Zelle, because I don't know anyone who uses it, but I've tried going through the workflow a few times)
Actually, this is especially true when both are 1080p, because laptop screens are never as big as desktop monitors, and we also tend to use them closer. I have this exact problem right now but I think I've just adjusted my eyes over time to squinting at 1080p at 14", or perhaps I turned on some display scaling and forgot about it.
> For example, you can have a window that straddles both monitors. What should the scaling be?
Intuitively, I feel like you should use the physical DPI of both screens to make sure that the window has the same physical dimensions on both. But that'd probably lead to weird scaling factors like 1.17 instead of nice round ones, and thus fuzzy scaling, so it probably couldn't quite work. I guess perhaps you'd just snap each display's DPI to the closest predefined value (eg. .25 increments which I think most systems use these days). Then you'd get a similar-sized part on both sides of the boundary.
But yeah, I think overall if you actually use physical DPI for scaling everything should work out close to nicely.