beaviskhan

Probably not - but by calling out EC2 instances as the way and then failing to mention patching or configuration management, this article loses some credibility for me. These considerations are not optional over any significant length of time, and will cause misery if not planned for.

Bare minimum, script out the install of your product on a fresh EC2 instance from a stock (and up-to-date) base image, and use that for every new deploy.

Also Not Awesome - AWS Config rule evaluations

Seriously, integrating with a single vendor is often nightmarish. And this guy is proposing some unholy vendor centipede? Harrrrrrd pass.

You can keep it non-cloud as far as I know. I just bought a gen2 cloud key to replace the [persistently crappy] gen1 cloud key that I've had for ~5 years and I was able to skip the cloud login during initial setup. Of course, the devices reach out to fetch updates and whatnot, but all auth/config is held locally.

No mention of their return policy? IMO this is a huge part of the attraction of Costco - if you're not satisfied with a product for any reason, you can return it, full stop. They've had to rein in some of the more generous practices due to egregious abuses by customers (ie returning a TV after 2 years) but in general, buying things at Costco is a no-risk activity for a much longer time than any other mainstream retailer.

Accurate. And, if there is significant rain and/or snowmelt, roads can quickly become impassable (see: "mud season" in New England, and surely many other places)

The vast (VAST) majority of the "YAML sucks" examples are solved just by quoting all your weird literals. YAML is definitely annoying at times (list of maps get weird in a hurry, for example, and significant whitespace almost always bites you sooner or later) but these kinds of articles seem disingenuous at best.

Deleting comments, ugh, please don't do this :( If you must, make a throwaway account instead. It sucks to find a thread that promises to solve a problem you have, but when you go there critical context is missing due to deleted comments.

I will say, it seems better than it used to be in the pre-chip days, but I've had to replace my primary CC once already this year due to an obviously fraudulent charge. To the credit of my bank, it was virtually painless - I had a new card in under 24 hours, and I didn't have to think about the $2000+ charge at all until they confirmed (two months later!) that it was in fact fraud.

I assume the rest of the world is less stupid/greedy than the US here, but honestly I have no idea how this works elsewhere - that's the reason for the "US resident" clarification.

There is zero chance that I, a US resident, will ever use debit cards for anything. The reason is that in the event of a fraudulent charge (which still happens surprisingly often, given that chips were supposed to put an end to that):

- With a debit card, I am out $X of my own money, until the bank can be bothered to agree that the charge is fraudulent and refund my money, which can take weeks or months, if at all. Good luck paying rent or buying food or whatnot in the meantime if you don't have a nice savings cushion.

- With a credit card, I am out $0 of my own money, and now the bank is potentially out $X of THEIR own money, making them significantly more motivated to investigate promptly and agree that the charge is fraudulent. For however long this takes, I still have my own money to pay rent and buy food, and I'm not on the hook for paying the fraudulent charge.

The fact that credit cards tend to have "rewards" in the form of cash back or airline miles or whatever is secondary to me, personally, although I do take advantage of this as much as possible.

> To know the difference between SRE and DevOps ask them what they do when an incident happens: > DevOps rolls back (reverts the changes, treating the system as a black box that should go to the last known good state) > SRE fixes forward (fixes the problem and commits a new change)

Ehhhh. I don't think it's that simple, and you'd better know what your strategy is for incident response BEFORE one happens. By far the worst shitshows I've seen in production have been as a result of well-intentioned people trying to fix forward without fully understanding what is going on.

Spoiler: having full understanding of what is going on in the heat of the moment is really, really hard, even for smart people who are also system experts. Rolling back as a default and then figuring out what went wrong in a more orderly manner is a perfectly sensible default behavior where such a thing is possible.

It's been a while since I used this tool, but as best I can recall there was a way to provide usage estimates to feed the variable cost calculations. The biggest problem we had was getting development teams to know and care enough to provide accurate numbers. The suggestion in the post below to provide 30 days historical data as a starting point could be a great way to have a meaningful baseline. If someone had better projections, they could provide them, but at least it wouldn't be a total crapshoot.

I have used this tool in the past, though free tier only. It was easy to get up and running and easy to plug into a CICD pipeline. The problem we had with it in practice was that we largely preferred serverless technologies in AWS where the cost depended mostly or even completely on actual usage - things like Lambda invocations, SQS operations, or autoscaling ECS services, for example. In this case the estimates we got from Infracost were not very useful. Providing a meaningful cost estimate requires projecting usage, which is something that our development teams were very bad at, if they could be bothered to care at all.

I like the idea of implementing tagging enforcement in the pipeline. In a perfect world you would use cloud policies to do this, but in practice this is a big loser in AWS where a staggering number of resources are created by one API call and then tagged as a followup API call, meaning an SCP to prevent launch of untagged resources won't ever work.

Everything is terrible if you use it long enough. Some things are more terrible than others for certain use cases - a thoughtful developer understands the weak points of the tooling, and selects the proper tool for the job at hand.

In my small town, we approve apartment complexes without doing anything to accommodate the additional traffic they inevitably generate (in a small town that already has significant traffic problems and very little public transportation). The fight to deny these permits is warranted, in my opinion, until they're handled more appropriately.

Unfortunately it's an exceedingly complicated problem since a number of the main roads through town are actually US/state highways and as such, modifications require coordination between local, county, and state agencies, and often involve almost unbelievable lead times.

IMO - killing animals for the purpose of eating them is wildly different than trophy hunting. I'm fine with calling hunting to eat "harvesting", I would not buy that nomenclature for trophy hunting.

Make Terraform run only off git repos, and control commit rights to that repo. That's been a successful approach for me in the past when dealing with auditors.

Probably because he knows doing so would make his life harder and give him less data to scrape.

It seems like ChatGPT4 fails at basic math. Unless I miss something, the party as a whole is still 30 gold pieces short of what is needed to equip them all with 95gp worth of equipment.

---

The total cost for each character is 95 gold pieces. Subtracting this amount from their starting gold, the remaining gold for each character is:

    Obie: 75–95 = -20 gold pieces (Obie will need to borrow 20 gold pieces from another party member to cover the cost)
    Tenzin: 75–95 = -20 gold pieces (Tenzin will need to borrow 20 gold pieces from another party member to cover the cost)
    Liam: 100–95 = 5 gold pieces
    Taylor: 100–95 = 5 gold pieces
*

With AnyConnect you can definitely work around enough to make WSL2 + dockerd functional: https://gist.github.com/pyther/b7c03579a5ea55fe431561b502ec1...

Was there a tech-hiring bubble, or has everyone just realized that posting on Indeed gives you garbage results, and has adjusted their posting activity accordingly?

That's not entirely fair - the default has been to ALLOW people to set buckets to public and/or to set public ACLs on individual objects. Both of these require the customer to Do Something in order to grant public access. The default has NOT been "public access for all" ever, that I am aware of.

The biggest downside I've found with Graviton is that it's gotten popular enough that availability of capacity is a problem in some regions/AZs - particularly if you're using larger EC2 instance types.

Also, Fargate Spot on Graviton is still not available, so if you want to run Spot in non-production environments, you're facing with running different architectures in prod vs. non-prod, which I don't like at all. Do the math on whether it's cheaper for your use case to go x86 spot/non-spot vs. Graviton non-spot.

Yes, and if you interrupt me to ask me if I'm angry, then I'm going to both look like I'm angry and actually be angry. Leave me alone, I have work to do! :p

You can't have multiple yubikeys associated with your AWS account! And you can't have a yubikey as primary and a software authenticator as a backup, for example. It's a huge hole in their operation imo. Even comparatively unimportant apps such as Facebook allow you to associate as many hardware tokens as you like, fallback to authenticator or SMS, etc.