pluies

You can also use Thanos (https://thanos.io/) for storing Prometheus metrics into S3. The design is pretty similar to Loki (which Thanos predates), separated into services so you can nicely horizontally scale your ingestion path separately from your read path depending on workloads.

Sure, cameras in todays smartphones are great and take beautiful pictures, but bird photography is pretty much their achille's heel - tiny fast-moving objects would require much better zooms, higher iso, and lower shutter lag than what's currently available with smartphones.

I assume the new round would be of heavier kettlebells as OP continues to develop strength? If not, I’d also be interested in knowing how one wears out kettlebells!

> Another concern I have is that if a feature toggle isn't enabled in production for a long time (for us, several days is already a long time due to a tight release schedule) new changes to the codebase by another team can conflict with the disabled feature and, since it's disabled, you probably won't know there's a problem until it's too late?

Reminiscent of Knight Capital losing $440 million in 45 minutes via feature flags: https://dougseven.com/2014/04/17/knightmare-a-devops-caution...

That's the notation adopted by the Long Now Foundation (https://longnow.org/) rather than octal, I believe

Agreed that the bread in the photo looked very sad!

I don't agree with your comment about UK baguettes though. In London at least, you can get very good baguettes from Orée, le Pain Quotidien, (to an extent) Paul, and a bunch of small local bakeries here and there. As a Frenchman, I find these to be just as good as what you'd get in any French bakery.

At the time of writing, TFA mentioned a fine of 6,500,000NOK in the first paragraph rather than 65,000,000NOK - probably where the confusion comes from.

The HN headline is also "wrong" (or at least imprecise) - the fine amount is in NOK, so the euro figure is ~6.418 million depending on exchange rates.

Just a nitpick: it's Yvon Chouinard, Yvonne being the feminine version of this first name.

https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref... :)

This could lead you to the wrong place if, for example, some quoted values on this row contains commas, no?

Has something made it more difficult? :o I ordered a Oura ring in the UK about a year ago, and it was just a standard online purchase.

Note that in the EU this would be a pretty bad violation of GDPR, so going to your local branch of government responsible for GDPR enforcement (e.g. the Information Commissioner's Office[1] in the UK) would be another good avenue.

[1] https://ico.org.uk/

> Being able to automatically provision a resource in AWS, then use results from that in a Kubernetes service (env var) in the same deployment, is not something I ever expected to be able to automate.

Terraform does this very well too, using either the Kubernetes provider or the Helm provider.

(Not the OP, but running a fairly similar setup, albeit for EKS nodes rather than ECS nodes :) )

Fargate Spot is about a third of the price of Fargate (at least in eu-west-1 now according to: https://aws.amazon.com/fargate/pricing/ ); so the savings are roughly identical.

Re risk of running out, our current strategy is to use different-but-closely-similar instance groups; so for example we have an autoscaling group running a mix of:

- m5.large - m5dn.large - m5n.large - m5ad.large - m5d.large

Which are the same price on Spot instances, but I'd wager it'd be pretty rare to have all these families reclaimed at once.

(We also use some on-demand only ASGs with lower priority in the cluster-autoscaler to ensure that if it _does_ happen, then we'll have a fallback)

I used to use this a lot, but when I tried yesterday (and same today) I got a Heroku error message :(

Not sure if it's temporary down or fully off.

From the article:

> Why the worker count varies

> The rule I used for deciding on what the optimal number of worker processes was is simple: for each framework I started at a single worker and increased the worker count successively until performance got worse.

> The optimal number of workers varies between async and sync frameworks and the reasons are straightforward. Async frameworks, due to their IO concurrency, are able to saturate a single CPU with a single worker process.

> The same is not true of sync workers: when they do IO they will block until the IO is finished. Consequently they need to have enough workers to ensure that all CPU cores are always in full use when under load.

While I 100% agree that having doing most of the tracing at the sidecar level is the right call, you'll still need "some" application-level awareness of tracing (e.g. passing along b3 headers: https://github.com/openzipkin/b3-propagation ), or you won't be able to match various spans to a common trace and lose a _lot_ of value from your distributed tracing.

You don't even need ML for that - if someone ran a segment twice as fast as the olympic record for that distance, it's pretty obviously wrong... And yet, that happens pretty regularly for segments I look at.

This post certainly rings a bell! Even with deep Kubernetes experience, we struggled at times with Istio at $previous_job, especially around:

- Control-plane performance on a cluster with a large-ish number of pods (thousand+) can be hit-and-miss, and "what to scale up" was hard to pinpoint (though admittedly it seems to be getting better)

- Istio upgrades often are a pain, but mostly around the actual way of deploying the upgrade, rather than the upgrade itself. For a long time there was no official Helm chart, then there was a Helm chart, then two Helm charts, now it looks like Helm is deprecated and will be removed; instead installing via `istioctl` is recommended... Some of it is due to the pain of upgrading CRDs, which is a general Kubernetes issue, but there's still a _lot_ of churn to keep up with.

- Adding a new VirtualService registered to the same hostname as an existing one will be accepted by Istio (at least as of 1.4), and will proceed to _silently break all routing for new pods joining your istio cluster_! This was a bear to debug too, given how noisy and confusing the Pilot logs are, and we ended up stitching up a custom Prometheus alert around this given it bit us roughly every other week

- HA for control-plane components isn't explained in the docs. Is it safe to run two Citadel pods? We did it and it seemed fine, but who knows?

- We sometimes ran into pathological cases where traffic would for some reason completely drop after a new deploy, and gradually pick up after the config was stremed onto sidecars, over a span of ~10-15 minutes. We never managed to debug this issue (which happened probably half a dozen times over a year), and that mere fact turned me off the complexity of Istio in general.

(Some of these might have been fixed in Istio 1.5+, as 1.4 was my latest experience)

Of course, once your setup is stable, everything is awesome: sidecar injection works flawlessy, observability is awesome, distributed tracing is a breeze, Kiali is a great crowd-pleaser when showing off features, mTLS + TLS origination mean full on-the-wire encryption without losing any of the previous benefits... A lot of features that meant we carried on with it, but if I had to start again I'd probably have a good hard look at Linkerd before recommending Istio for any prod setup.

Agree re noisy neighbours, but autoscaling depends on _requests_ rather than _limits_, so you could define requests for HPA scaling but leave out the limits and have both autoscaling and no throttling.

Hey, author here, thanks for the feedback! :)

Re the AMI - yes you could use a data block, but that would immediately apply the latest version of an AMI when executing terraform, leading to unreproducible builds. Zeitgeist instead would just notify you that a new image is available, but let you control when you choose to deploy it, for example once you’ve confirmed that the new image passes all your tests in a dev environment.

(And if the AMI is for an individual EC2 instance instance rather than an ASG, you’ll have to plan downtime while the machine reboots with the new AMI, so a data block can be pretty dangerous there)

Re Terraform itself; where you’re running it is irrelevant - it needs to be kept up to date somehow. As mentioned elsewhere in this thread, some of these updates (like 0.11 -> 0.12) need to be carefully planned and managed... and how would you do that if you don’t know updates are available :)

Hey there, author here - good point, I’ll add Akamai! Long story short: standard gzip results, in line with nginx / apache / gzip command-line.

That doesn't look so bad? From what I can see, it's probably just feature branches all coming from a single point (e.g. previous release) being merged one after the other. Any active project with a team upwards of a dozen people will look the same and possibly way worse.

(n+1).(n-1) = n^2 - n + n - 1 = n^2 - 1

Do you have any source for this trial? I can't seem to find any trace of it when googling. Also Henry Ford died in 1947 and had cerebral issues before that, so if the trial did happen in the 50s it was either brought by his successors or Ford Motor Company.

My first reaction upon seeing your username and remembering previous HN discussions related to your actions was "oh, it's you!".

Keep up the good work. :)

Falkvinge, at: http://falkvinge.net/2012/09/07/three-reasons-child-porn-mus...

My own answers, with test data: https://gist.github.com/Pluies/5663135

Despite thinking I knew SQL reasonably well, I wouldn't have fared very well at all in an interview setting. :/ Took more time and googling than expected.

Meet the airline I booked with yesterday: two email fields, with paste disallowed only on the second one.

:(