I took a peek at the terms of service[1] when considering signing up for an account. It seemed unusual to have them in a separate language from the rest of the site.
Presuming the translation was correct I would "agree to comply with Chinese laws ... [and] grant the company a non-exclusive, free, perpetual license for global use (including modification, display, and derivative development)."
The referenced terms (including clauses like perpetual licensing) were placeholder text I generated with ChatGPT during development. Currently, my website doesn’t store any user code—even if you’ve registered—except for an unused article feature.
As a bilingual service, I recognize how misleading these provisional terms appear and will remove this page immediately.
The personal plan[1] repeatedly emphasizes the word free and makes no mention of the $30+/year optional fees or what features differentiate the levels of service.
Meta: In HN, prefix a line with 2 spaces to get code formatting, ex.
# syntax=docker/dockerfile:1.3-labs
FROM alpine
RUN <<EOF
echo "This is a heredoc example"
echo "It allows multi-line commands"
EOF
Non-meta: Do you happen to know how portable that is across old docker, podman/buildah, kaniko, etc.? I'd like to adopt it but I don't want it to bite me when I'm not running a recent version of literal docker.
Some people play lip service to superstitions like this as a form of fun or a way to communicate feelings on a topic, and not necessarily because they believe the superstitions.
For example, if I followed up a statement with "knock on wood" it wouldn't be because I believe it helps, or expect anyone to actually take that physical act (I probably won't unless to emphasize my feeling more), it's to convey I hope something succeeds or does not fail in a way that provides a lot of context in a small amount of words.
> Those people who think they know everything are a great annoyance to those of us who do. -- Isaac Asimov
Useful discussion is an interesting scope for someone with the broad, in-depth knowledge of a vast array of subjects he demonstrates in the linked essay.
You make a decent point. There's a clear limitation... but a clearly worded prompt often produces more valuable content than an SEO optimized guess article.
The vulnerability sounds like it's inherent to SQL Server, and that cloud providers haven't been successful in blocking the underlying problem due to its proprietary nature.
Presenting it as a Cloud SQL problem is disingenuous.
> we identified a gap in GCP’s security layer that was created for SQL Server. This vulnerability enabled us to escalate our initial privilege and add our user to the DbRootRole role, a GCP admin role.
So Google took proprietary software not designed for this use-case and built their own security layer on top of it and ended up with bugs.
Of course that's an issue with the service. Presenting it as anything else than an issue in Cloud SQL seems disingenuous.