There’s far worse problems with Discovery ;) but really, much of Trek is ridiculous: “we went really fast around a sun and traveled back in time to _exactly_ when we need to be.” Convenient!
Not sure about Google but Apple has per-app time limits, per-app type time limits, overall screen time limits, time of day limits, parental review before app install, parental review before purchases can be made, etc. I've found it to be quite robust in managing my kids' access to the internet.
I have had fairly bad luck specifying the JSONSchema for my structured outputs with Gemini. It seems like describing the schema with natural language descriptions works much better, though I do admit to needing that retry hack at times. Do you have any tips on getting the most out of a schema definition?
To add to the confusion, you can also just use Gemini via API (without Vertex AI). It shows up as a separate item in billing.
In the (latest, of three different) Go SDK, you can use either Vertex AI or Gemini. But not all features exist in either. Gemini can use uploaded files as attachments, and Vertex AI can use RAG stores, for example. Gemini uses API key based authentication, while Vertex AI uses the traditional credentials. All in the same SDK.
I don't think the "be nice to everyone" is the thing people are annoyed with, rather it's the "you will be canceled if you step out of line even once" that comes along with it.
Can you get a working game generated? All I ever see is at least "Script error." with no clear way to debug. Having bolt try to fix it seems to just regenerate bits of the app but has failed to actually fix any problems so far.
After some initial pains with colima, I tend to agree. Mostly, just needing to specify some VZ args[0] so I could run x86_64 docker images on my M-series.
Is there something in these desktop UIs that colima is completely missing?
Yep, that whole example after the float cast is bit silly. After the cast, the value can never be an empty string, or null. Not to mention, comparing a floating point value to an arbitrary, literal value (of zero in this case) is potentially problematic [1].
For what it's worth, I actually agree. See: Curiosity or Ingenuity, both relatively new and far outperforming their expected life. Not to mention that I'm sure the ground-based transmitters that were used to actually fix Voyager 2 are likely not old, so it really isn't a case of "old is good" which helped in this case.
My comment is unfortunately an example where I let my late night shit-posting bleed over into HN, which is always regretted in the morning. Apologies ;)
There's definitely some ambiguity there, that's a good point.
I'd probably say that users_facts would be a to-many join table between users and facts, like if you had one row per fact and a multiple facts per user though that example doesn't really make sense here (could just have the FK exist in Fact and not need a join table). If UserFacts were stored in a table with multiple facts in one row about a single user, I would probably call that table user_facts.
Would probably also be fine with running across either in any codebase (or even singular table names, for that matter! as long as it's consistent :D )