jeremya

It’s a thneed!

This is fantastic. I’ve always enjoyed the cypher language that the neo4j team created for querying graph data. The connected k8s api objects seem like a great place to apply that lens.

Whether or not that is the case, surely the substance of the article more worthy of your analysis than something as intangible as the authors internal motivations? Assuming positive intent is worthwhile frame of reference that keeps my world looking a bit brighter and something I always hope other do for me.

> Any principal in your management account, by default, is able to assume the OrganizationAccountAccessRole in each and every one of the accounts created using the organizations:CreateAccount API.

This is an untrue statement. For a principal in the management account to assume OrganizationAccountAccessRole, they need to have a principal-based policy that gives sts:AssumeRole permissions for it. Otherwise, great article. We use this pattern at $DAYJOb

I think this feature lends itself well to tight feedback loops, as you said. However, after I crossed the painful divide from CloudFormation novice to... well, whatever is after that, CloudFormation rollbacks became a friend instead of an enemy. The ability to return to the last known good checkpoint is a powerful feature that is extremely useful in production systems and the pipelines that deploy them. In those scenarios, you're not experimenting and learning, but enhancing and evolving existing infrastructure.

Copilot generates CloudFormation templates based on the Copilot-specific config files. There’s a place where you can add your own additional resources in CloudFormation syntax IIRC. It also has the ability to create a CodePipeline for app deployment. That creation is also done by generating a CloudFormation template and deploying it for the user. I’m not sure why it’s not clearly documented that this is happening, but it is a selling point to me because if I want to, I can “eject” from Copilot and just maintain/enhance the CloudFormation templates.

I found this very helpful. It gives clear language for a number of things I’ve thought and felt about public discourse in America. To name a few in particular, the belief that complicated explanations are suspect and that certainty is strength. I’ve repeatedly observed that successful people seem to have very strong opinions and wondered if that was a contributor to their success.

While it seems most things in this list stem from one or more logical / informal fallacies, the way the principles are categorized and described makes the fallacy obvious and, for me, familiar. Since 2003 when this was published, I believe the network effects of social media have significantly increased the frequency at which these sorts of fallacies are uttered.

What are the systems at work here that lead to this so-called cargo cult? Is it easier, psychologically speaking for people, and Americans in particular, to walk with these mental crutches? Is our education system broken? What variables are at play here?

This is interesting. I think the weird underscore between words (which indicates space) is throwing me off though. I'd recommend removing that.

What do folks think about this? I have encountered the licensing challenges of local development with RHEL 7 containers. The workaround for it put us in a weird spot with licensing even though we were paying for RHEL 7 on the host OS. We had reached out to our Red Hat reps and even they did not seem to understand the issues at play. It seems like this move will really simplify the whole thing. The post is a little unclear on the technical details. Will these images have access to install packages from RHEL yum repos even for users who do not pay for RHEL support? Also, what, if any, effect do folks here think this will have on CentOS? I certainly like the option of being able to start with UBI or UBI minimal images with no support and being able to buy support when needed without re-tooling the stack.

I see that the course begins on August 27th. What is the deadline for applying to Startup School?

I think this article may be guilty of overstatement. It's an ever more common sin, as overstatement seems have become a preferred method for communicating thoughts and ideas (and products, though that's nothing new).

Is there a need to overstate to cut through the noise and get your point across or your message heard? Maybe, but it seems unfortunate that when people have some truth or wisdom to share, there is a felt need to amplify and polarize it.

This article has good things to say about the importance of simplicity in code and implementation. I'm fine with value judgements as long as they convincingly define the values they are judging and show evidence that the facts have been thoroughly weighed. 'Correctness' is an ill-defined villain here and the article would do better to state the benefits of simplicity and experiences the author has had with systems designed without simplicity as a first-order goal.

Then again, perhaps I ask too much. Also, I've never had an article on the front page of Hacker News, so what do I know.

It's not exactly the same thing. Encryption at rest on S3 is good, but security is about layers. If you only use that, then you are one mis-configured S3 bucket policy away from exposing your secrets. Bad bucket policies are one of AWS' biggest footguns- plenty of intelligent people have done it before, don't assume it's a mistake you'll never make. It's so easy because S3 is a service that has to make publicly-accessible storage easy to achieve.

KMS keys on the other hand, do not have that use case. If the secrets in your S3 bucket have been encrypted using a KMS key (or better yet, a data key derived from a KMS key) and your bucket is compromised, your secrets are safe as long as the attacker cannot ALSO get access to the KMS key. By all means, enable encryption at rest on S3, but don't make that your only defense.