Oh man, I got excited to use this with our kids, but then saw that it requires a " mobile device management (MDM) solution and Managed Apple IDs." I hope they consider the family use case in the future.
In this size class, Chromebooks and ChromeOS tablets could be a better fit.
Perhaps Samsung's tablet could be more polish, but for many use cases Chrome OS is more flexible and will "just work". And to the subject at hand, user switching is pretty decent, all the more so if you keep nothing local.
Is it actually balanced? With huge documents like these, the tendency is to add in artificial balance to placate various government factions, interest groups, etc. Often the document still has a preferred view that you can distill once you brush aside the filler.
Edit: just read the foreword (what would be called the “executive summary” in an American document). Seems like the Twitter thread describes that pretty well. And since the document authors know that the foreword is what most of the readers will read, that’s pretty indicative of their views.
Love seeing more innovation in this space! I know Oleg (former Webflow eng) has been working on https://webstudio.is for a while; also open-source and visual editing for React apps. How does Onlook compare?
Webstudio is very good! I didn't know it produces React.
Onlook has less abstraction between code and the visual editor. It works with your existing React codebase with no migration. Everything is written into code in real-time so you wouldn't import or export the code from Onlook. You can use it anytime and stop anytime like an IDE.
Does this make sense? I'd love to hear Oleg's thoughts on this as well :)
We are generating React/Remix app atm, but our architecture is designed to support other frameworks as well.
It is achieved by using data as a source of truth, not the code. Web tooling is very fragmented. People have too many opinions on how to write components and that makes it nearly impossible to have components written by hand and then synced back into the UI without enforcing a huge amount of constraints. You will end up writing code in such a way that the UI can handle.
I'm a fan of the Red Hat font family, i.e. Red Hat Display, Red Hat Text, and Red Hat Mono. They are available via CDNs, font providers, and directly from Red Hat:
To be fair, the person could still use Google Fonts, but just download the font and host it themselves. The font licenses allow this.
You get the upsides of being able to pick a nice font from Google Fonts while not having the downside of tracking. It also helps with caching! And also prevents the font from disappearing for no reason.
Absolutely, if you're building a GraphQL server, parsing is almost certainly not your bottleneck. Stellate is effectively a GraphQL CDN, so for us, it is.
Our request flow effectively boils down to:
1. Parsing a GraphQL query to assess which types and fields are within it
2. Matching the configured cache rules to those types and fields
3. Caching partial results accordingly
So, for our specific use case, parsing is one of the main things our edge gateway does, and reducing overhead there allowed us to significantly improve our overall performance.
It was posted by the tech reporter at NPR. Inb4 “journos can’t be trusted” blah blah blah, here in reality NPR is a reputable org and a reasonable person’s Bayesian priors would put this at “almost certainly an actual statement from ScarJo.”
Variety has a story.[1] It doesn't yet mention an direct statement from Johannson. But watch that space. Variety is well connected in Hollywood and will check with her agent to confirm or deny.
Variety article updated: [UPDATE: Johansson released a statement saying Altman had reached out to ask her to lend her voice to ChatGPT but she declined; when she heard the demo, “I was shocked, angered and in disbelief that Mr. Altman would pursue a voice that sounded so eerily similar to mine.”]
