henridf's comments

A timelapse of a building being moved in 2012 in Zurich: https://vimeo.com/42984680

It's taken from close up so you see how a concrete platform has been poured under the building, then the whole thing pushed on rails.

Prometheus is a (rare) recent example of a significant, thriving open-source project that is community-based. Not quite as broad in scope as something like Elasticsearch though.

For those wishing to see Sqlite used to publish data sets:

Datasette (https://github.com/simonw/datasette) is a new tool to publish data on the web. It uses SQLite under the hood.

OP here, my bad indeed. I was fiddling around trying to figure out the right way to shorten and carelessly ended with this. No intention to mislead, but I agree this changes the meaning in a bad way.

Most importantly I don't see a way to revert; hopefully the moderators will see this and do it instead.

I'm not sure which tools the author has tried, but the Prometheus monitoring system supports both histograms and quantiles.

There's a good discussion of the respective merits of each at https://prometheus.io/docs/practices/histograms/#quantiles

Is m3ql still being used? And if so any thoughts on how m3ql and promql will respectively be used over time?

We ran into a number of issues with Helm when deploying - failures leading us to have to rollback, with rollbacks then failing, requiring manual changes to unblock.

I think that for third-party packages and related templating (which seems like the original use-case) it works well, but I would be wary of using it for high-res deploys of our own stuff.

Minikube is working great for us. Makes it easy to run something that's pretty close to a production stack on a dev machine.

Typically with locally-built (dev) images rather than those from the registry that CI writes to, but other than that the k8s manifests are the same.

Sysdig has had a bunch of nice posts over the last 2-3 years:

https://sysdig.com/blog/tag/technical/

And details on the wrk (load gen) setup too, please.

Looks like a nice tool, and it's great to see syscalls getting more attention.

I don't fully get the argument for why on-host filtering is undesirable. Of course naively filtering for curl-originated connections isn't a solid detection scheme for rootkit-installs! That's just a naive filter, which a naive user could mis-use in a centralized way or in a distributed way.

As for event correlation (#2 of the pros), it can be done on-host too. And back-testing (#3) of new rules is indeed a highly valuable feature! But you certainly don't have to log everything centrally to get that capability. E.g. in the case of Falco, you can capture trace files and re-run any number of rules/filters on them.

I do agree with the point on rules being exposed to an attacker.

[Disclaimer: author of the initial version of Sysdig Falco]

Third-party Node.js bindings:

https://github.com/henridf/apache-spark-node https://github.com/EclairJS/eclairjs-node

Another scenario:

US Citizen living and working abroad buys a house for X in local currency. Later sells same house for the same amount X in local currency. That local currency has appreciated by 20% against USD in the timeframe. And the IRS computes capital gains in USD, not in local currency.

Net result: the seller owes IRS "capital gains" taxes on 20% of the value of a house that was bought and sold for the same price.

I recently looked into notebooks and found Beaker (http://beakernotebook.com) to be especially interesting in its support for passing data across languages.

You could look at this as a very high-end acquihire.

The Juttle query language allows the expression of dataflow graphs and UDFs which can not (in general) be done natively in ES.

As far as the scaling issue goes, this was designed to run on premise rather than as a SaaS service (unlike bigpanda?).

Disclaimer on last paragraph: as per @demmer's comment below, Jut's plans have changed, so it may no longer be valid or relevant.

Indeed storage choices are plenty. That said, if you want to be able to do the kind of optimizations that are described in the article, then the set of candidates gets a bit smaller.

> "You can also set up your Lambda functions to run for up to five minutes [..]"

What was the previous limit?

Makes sense. How do you deal with data arriving out-of-order? (assuming your data is timestamped at the source)

Rather than build your own, did you consider moving to another distributed stream processing platform such as Spark Streaming or Flink? If so, curious to know what disqualified them.