The async process sounds promising but unfortunately eglot doesn't work with it. I got a message from reddit that tramp 2.8.0-pre has fixed that issue but until last time I compiled HEAD from tramp repo it still doesn't work.

I just applied other configurations from the article and it seems faster than the default settings. Thank you author for sharing this!

Isn't recent Tramp versions using this by default?

Yes, this is a common confusing point between structured logging and wide event. The Wide Event 101 article I referenced has clear explanation:

> Structured logs could be wide events, but not all structured logs are wide events. A structured log with 5 fields is not a wide event. A structured log with no context is not a wide event.

And these also why it requires no code changes to extract more metrics from wide event. The context can carry enough information and you just write a new query to retrieve it. In current metrics tooling, you will make code change to define new labels or add new metrics for that.

> And these also why it requires no code changes to extract more metrics from wide event.

I think the point of OP's comment is that while you're not paying code tax for to parse/aggro the data as it's all in one place you're paying code tax for actually generating the event with everything in it.

Sure you still need to code but instead of concrete metrics one by one, you instrument the context and the state. The opentelemetry trace API can save you a lot of work. But I agree there is still potential to improve the auto instrument.

Author here. Thanks @todsacerdoti for posting this.

I am big fan of the idea to have original data and context as much as possible. With previous metrics system, we lost too much information by pre-aggregation and eventually run into the high-cardinality metrics issue by overwhelming the labels. For those teams own hundreds of millions to billions time series, this o11y 2.0/wide event approach is really worth it. And we are determined to build an open-source database that can deal with challenges of wide events for users from small team or large organization.

Of course, database is not the only issue. We need full tooling from instrument to data transport. We already have opentelemetry-arrow project for larger scale transmission that may work for wide events. We will continue to work in this ecosystem.

I have being using andOTP for years but the development seems to halt, also it's no longer available from f-droid. The feature that backup with gpg encryption is broken.

I hope it's possible to import my otps from andotp into aegis. Also the backup encryption with gpg (openkeychain) is welcomed.

I have been a happy long-time user of andOTP since migrating to it from FreeOTP (iirc) and was unaware that it was no longer maintained. Some quick digging shows that the Github repo links to this XDA post[0] where the author announced he was ceasing development. :(

The good news is that migrating to Aegis is quite simple. Export from andOTP, in Aegis go to Settings -> Import & Export -> Import from File, & choose andOTP. Pick your file and away you go.

It doesn't seem to have a database of icons like andOTP does though; none of my imported items show an icon though several did in andOTP. (Could this be because of the method they were added?)

[0] https://xdaforums.com/t/unmaintained-app-4-4-open-source-and...

Old andOTP user turned new-ish Aegis user here: it's super easy to migrate and Aegis just feels like a better product.

Yes it's possible to import from andOTP

Like linux, most firefox users has tracking protection so data is not collected for them.

While using data lake for this case is a good idea. I'm not sure if parquet is the particular good storage format for data like event log, audio log. The data is often row oriented and does not take full advantage of a column based format.

By using metrics we make it a lower dimensional model, that can be managed at scale. However in real world, it often becomes a overfit one. In large scale execution, people only care what metric measures.

A talk vs metrics is just higher dimension vs lower one. The information within a talk is complex. Different people received vary information from the same talk. So it's hard to managed by scale.

So a metrics system is just a trade-off for its scale.

So sad to see he is leaving Clojure community. That's a sign of the death of Clojure. A few great developers have moved their focus away from Clojure.

Where are you getting this information from? Phil works for CircleCI, who have been very open about how much Clojure they use, and his GitHub profile indicates anything but: https://github.com/technomancy .

The reports of Clojure's death have been greatly exaggerated.

Mainly from people who just want the language to fail for some reason.

From the looks of things he recently joined CircleCI which is using Clojure, so maybe not all is lost ;-)

Where do they move to?

Here is an example that using Rust-native library for web development: https://github.com/tcr/rust-todomvc

Also I forked it to use handlebars: https://github.com/sunng87/rust-todomvc

Using asmjs, the compiled js file is about 20MB and can be slow in browser. While wasm32 one is just ~500KB.

Can wasm be chunked up and loaded on demand via AJAX, like JS?