Hacker News new | past | comments | ask | show | jobs | submit | mcstafford's comments login

I prefer heredoc[1] syntax.

I find it more readable and portable.

[1] https://www.docker.com/blog/introduction-to-heredocs-in-dock...


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.


It is new feature and not portable to old versions. But modern podman supports it. No idea about kaniko.


Whose popularity do you champion, and what sorts of motive bring deservedness in to the discussion?


I suspect science has had more to do with the reduction than superstitions like jinxes.


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.


I pray to god people let go of their superstitions.


:-) Delicious irony


Jinxing means you hat people might consider the problem solved and pay less attention to it.


> 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.


No? From the article:

> 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.


I'm a little curious, but haven't heard a word of what you're referring to. A quick search for 'atoms stalled' didn't result in anything that felt helpful.

Do you have a link that would clarify?


I assume they mean "atoms" as in physical material. I think they're saying physical sciences are stalling out and computer science is responsible for most growth now. I'm not familiar with this term though, and disagree with the sentiment.


In other words, we expected flying cars, but then we got Facebook instead.


One thing we seem to have discovered is that absolute randomness is harder than it might first seem.

Your idea combines what feels like a significant percentage of randomness while still having enough participation to rationalize buy-in.

It's tough to want to yield control of an important choice to a random number generator... though that's not an inaccurate description for this.

I like this as a perspective on "the illusion of choice". Part of me hates the phrase because I want to believe that I can take meaningful action.


Apple reminding me why I don't buy their hardware.


The Cliff comparison is a good one in that it very confident declares its every answer was though it is well-founded fact.


Consider applying for YC's Summer 2025 batch! Applications are open till May 13

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: