placardloop

13 years is an incredibly long time for something as fast moving as data center development. I guarantee that a _lot_ has changed. I know AWS in particular has gone through multiple entire revisions of their DC designs, and I recall a talk from some of their engineers saying how AWS actually found it more economical to use less cooling and let their DCs run hotter than they used to.

Here’s a recent article from AWS about using closed-loop systems for their AI data centers: https://www.aboutamazon.com/news/aws/aws-liquid-cooling-data...

My significant other is going through this situation, and in my experience it seems as though most doctors just simply don’t care to actually find a diagnosis (or at least, don’t have the time or motivation to care), combined with a hefty dose of “that’s not my job”. My SO has been to specialist after specialist who spends a grand total of 2 minutes listening to the symptoms, followed by “well let’s do some blood tests and see what they say” (ignoring that the last 5 doctors already did blood tests). And then when the blood tests come back with nothing obvious, the doctor just throws up their hands and says “well I don’t know what to do, you should go see <other specialist>”.

The reason the “family member or friend who knows someone who can recommend a doctor” seems to work well, in my experience, is because that doctor then has some motivation to actually care, as the patient is connected to someone they already know and care about.

Our medical system financially incentivizes doctors to see as many patients as possible, but doesn’t financially incentivize actually making them better. For that, the system just hopes that doctors will care, without giving them the room to do so.

There’s a massive, incredibly dense neighborhood of houses and offices less than 1000 feet to the south, west, and north of every one of SFOs runways.

No, they’re not. Of the 20 largest airports in the US, all but one of them have homes and offices surrounding them. The one that doesn’t is Denver, that’s mostly only because Denver’s airport is relatively new and the development hasn’t reached it yet.

Your comment stated “nobody is, at all, forced to use any of the AI tools”, which is entirely false - I’m looking at an email in my inbox from my VP right now saying everyone must use AI every day.

You said “None are installed by default or enabled by default anywhere” - this is also false. I’m looking at an installed by default (and uninstallable) AI browser addon on my work laptop right now.

It’s not hearsay, you’re either commenting in bad faith or you’re just clueless about what’s going on at your own company.

> There is absolutely no company-wide mandate

And now you’re just moving the goalposts.

If you truly believe what you’re saying, then you’re uninformed as to what is going on outside your own team. And just because it’s not happening in your team does not mean it isn’t happening.

Q is installed by default in all browsers on Amazon laptops now, and literally cannot be uninstalled. If you don’t have it installed in your IDE, you get a non-dismissible popup nagging you to install it until you do. Many teams are being told they must use AI every single day (some VPs have sent out org-wide emails saying that AI must be used), and engineers have to tell their managers how they are making use of it day-to-day. In my org, OP1 docs must include at least one section about how the team will increase use of AI. Hackathons aren’t allowed to happen anymore unless they are AI-themed. I could keep going. Amazon is absolutely forcing AI usage, and the article undersells how egregious it is.

MCP and Smithy aren’t comparable. Smithy is an internal tool used by almost every single team (it is used far, far more widely than just the SDK teams) at Amazon to define APIs and generate API servers/clients. It was released publicly because “why not?”, but I assure you that Amazon doesn’t care if you use it or not.

You’re right there won’t be any going back. You’re wrong about who is being smart about it.

If Apple wins appeal, they’ll happily and quickly reinstate the fees. It’ll be the app developers who then get stuck paying the fees because, as you mentioned, their users will be used to it and there’s no going back.

It’s not orthogonal. The foundation of good security is using your tools correctly. AWS explicitly tells users to not store sensitive information in policies. If you’re doing so, it’s not AWS making the mistake.

ListPolicies does not show the contents of policies, so the information you mentioned isn’t possible to obtain from there.

Things like GetKeyPolicy do, but as I mentioned in my comments already, the contents of policies are not sensitive information, and your security model should assume they are already known by would-be attackers.

“My trust policy has a vulnerability in it but I’m safe because the attacker can’t read my policy to find out” is security by obscurity. And chances are, they do know about it, because you need to account for default policies or internal actors who have access to your code base anyway (and you are using IaC, right?)

You’re right to raise awareness about this because it is good to know about, but your blog hyperbolizes the severity of this. This world of “every blog post is a MAJOR security vulnerability” is causing the industry to think of security researchers as the boy who cried wolf.

No, that’s not the reality. “Production data” isn’t as black and white as that.

Metadata about your account, regardless of if you call it “production” or not, is not guaranteed to be treated with the same level of sensitivity as other data. Your threat model should assume that things like bucket names, role names, and other metadata are already known by attackers (and in fact, most are, since many role names managed by AWS have default names common across accounts).

AWS does not treat metadata with the same level of sensitivity as other data. The docs explicitly say that sensitive information should not be stored in eg tags or policies. If you are attempting to do so, you’re fighting against the very tool you’re using.

This so called “security risk” is a role in a nonprod that can list metadata about things in your production accounts. It can list secret names, list bucket names, list policy names, and similar.

Listing metadata is hardly a security issue. The entire reason these List* APIs are distinct from Get* APIs is that they don’t give you access to the object itself, just metadata. And if you’re storing secret information in your bucket names, you have bigger problems.

It’s inaccurate to say that there’s “basically no zoning whatsoever in much of Texas”. In Texas, zoning is up to the individual cities. Houston is notorious for having a lack of zoning laws, but all of the other major cities like Dallas, Austin, Fort Worth, San Antonio all have very complex zoning laws.

My company sells AI tools, so there’s a pretty big incentive for to promote their use.

We have the same security restrictions for AI tools that weren’t created by us.

The article is typical security issue embellishment/blogspam. They are incentivized to make it seem like AI is a mission-critical piece of software, because more AI reliance means a security issue in AI is a bigger deal, which means more pats on the back for them for finding it.

Sadly, much of the security industry has been reduced to a competition over who can find the biggest vuln, and it has the effect of lowering the quality of discourse around all of it.

I’d be pretty skeptical of any of these surveys about AI tool adoption. At my extremely large tech company, all developers were forced to install AI coding assistants into our IDEs and browsers (via managed software updates that can’t be uninstalled). Our company then put out press releases parading how great the AI adoption numbers were. The statistics are manufactured.

You must not work in big tech, then. At my company, AI-companion tools were forcibly installed in everyone’s browser, soon followed by a press release parading how “100% of people at our company now use AI because it’s so great”. Attempts to uninstall the tool are explicitly blocked. Similarly, AI coding tools are forcibly installed in IDEs.

Every single hackathon or team workshop has been turned into a AI-specific hackathons or training. Managers have been told explicitly that they must come up with yearly goals that include the use of AI. Every project proposal must include a section answering how this project plans to utilize AI.

It isn’t even close to being the greatest tool in human history. This type of misunderstanding and hyperbole is exactly why people are tired/bored/frustrated of it.

The uncomfortable truth is that AI is the world’s greatest con man. The tools and hype around them have created an environment where AI is incredibly effective at fooling people into thinking it is knowledgeable and helpful, even when it isn’t. And the people it is fooling aren’t knowledgeable enough in the topics being described to realize they’re being conned, and even when they realize they’ve been conned, they’re too proud to admit it.

This is exactly why you see people that are deeply knowledgeable in certain areas pointing out that AI is fallible, meanwhile you have people like CEOs that lack the actual technical depth in topics praising AI. They know just enough to think they know what “good” looks like, but not enough to realize when the “good” output is just lipstick on a pig.

AI is really bringing out the worst in capitalist corporatism. I think even the most pessimistic AI doomer will agree that the technology is fascinating and can do some cool things, but our corporate overlords have made it such an all-encompassing topic that it’s hard not to be disillusioned by it.

Yes, it’s an interesting technology - but seeing other interesting technologies and projects get disinvested in because it’s not new shiny AI - or watching leaders insist on creating yet another chatbot just so they can pat themselves on the back - or replacing an already-working system with a half-broken AI one just so we can say we use AI, and then forcing everyone at the company to use it just so we can release a press release saying ‘all of our developers use AI’. Watching our overall quality of work decrease, but leaders celebrate it because “mediocre but done with AI” is gold standard now…

All of it feels like a sham. Feels like we’re trying too hard to prop up AI as amazing, rather than letting it succeed on its own merits.

Amazon Nova is a foundation model created by Amazon and is offered as one of the models you can use in AWS Bedrock, so the model gets a marketing page for it. Note that Llama also has an AWS marketing page (as do other models), but that doesn’t make them AWS products: https://aws.amazon.com/bedrock/llama/

Amazon Nova Chat is a different product that uses Nova, buts it not AWS. Notice that if you try to use Nova Chat, you log in using your Amazon.com account and not an AWS account.

This isn’t an AWS product, it’s Amazon (the non-AWS side). I don’t think this has anything to do with AWS billing.

AWS already has Amazon Q, which is its chatbot offering for AWS customers.

The GriGri does not have an autobrake. Petzl is very intentional in saying it is an “assisted braking device”, not auto braking. If there is any tension at all on the rope (even just lightly being held), then the GriGri will likely brake, but if the rope isn’t being held at all then there is no guarantee it will brake.

See this video, around the 10 minute mark where there’s several examples of the GriGri not locking at all: https://youtu.be/We-nxljgnw4?t=605

This is perhaps an even greater issue than what you pointed out because people misunderstand the GriGri a lot, and assume it will always catch them even if you aren’t holding the rope. It won’t.

It’s kind of funny that people think of “sandboxing” as the main feature of containers, or even as a feature at all. The distribution benefits have always been the entire point of Docker.

The logo of Docker is a ship with a bunch of shipping containers on it (the original logo was clearer, but the current logo still shows this). “Containers” has never been about “containment”, but about modularity and portability.

> Additionally, deployments to ECS are typically handled by invoking the AWS API within a GitHub Action, without continuous reconciliation or drift detection.

No they aren’t. All of the major IaC solutions (TF, CDK, etc) do ECS deployments directly through their own API, including with drift detection and updates.

Good for you for finding something that works, but it sounds like your advice related to IaC solutions is based on a misunderstanding of the benefits of IaC and the tools available.

Mentioning “no IaC management overhead” is weird. If you’re not using IaC, you’re doing it wrong.

However, GitOps is IaC, just by another name, so you actually do have IaC “overhead”.

> Having a (targeted, scope and time-limited) design discussion or giving your candidate some made-up context around an engineering cycle and then doing a retrospective with them

You just described a contrived, “unreal” problem.

> I'm also not sure what the alternative is? Just not hiring?

The alternative is to come up with questions that are representative of skills related to “real problems”, as you just did, and use those instead. Unfortunately candidates consistently complain that such questions aren’t realistic.

The “real problems” most companies want people to help solve involve the evolution of products that last for years, involve repeated design discussions, in depth research, and applying retrospective learning. I don’t need someone that can just glue a Rails API together. If I did, I can literally just download that from the internet for free.

If my problems could be solved in the time span of an interview, why would I waste my time doing that interview instead of just solving it?

+1 to all this. It still surprises me how many people, even after being in the industry for years, think the goal of any interview is to “write the best code” or “get the right answer”.

What I want to know from an interview is if you can be presented an abstract problem and collaboratively work with others on it. After that, getting the “right” answer to my contrived interview question is barely even icing on the cake.

If you complain about having to have a discussion about how to solve the problem, I no longer care about actually solving the problem, because you’ve already failed the test.

“Real problems” aren’t something that can be effectively discussed in the time span of an interview, so companies concoct unreal problems that are meant to be good indicators.