ehostunreach

> Try to keep context shoved in a conversation thread under a token limit to save tokens.

For big tasks/features, I'm always creating a new git worktree and I'm using a "status repo" skill that creates a sibling status git repository where everything is recorded.

It works quite well whenever I have to revisit something. It's quite token hungry but I have the full trace of what happened in the past.

https://gist.github.com/vkalintiris/3ad526e71a75bcba013aaadc....

Another approach I want to explore is using https://github.com/netdata/netdata (disclaimer, I work at Netdata) to send all OTel logs/traces of LLMs to it. The idea is to replace the status repo skill with something that will allow LLMs to retrieve the history of a given task/feature. It will probably require some "checkpointing" to make this more efficient.

> but every vendor still finds a way to pull you into their proprietary query dialect

We just finished adding support for OTel in our own product, and from the "vendor" side, I think there are two reasons for this.

The most important one is that query performance is tightly-coupled with the storage engine. While being OTel-compatible does limit vendors to follow certain specific storage/representation implementation choices, on the query side each vendor can (should?) use the query language/approach that fits best their own storage engine in terms of performance. After all, OTel standardizes the data transfer + wire model, not storage/query.

The second one is hidden within the blog post:

> Support for Semantic Conventions: Adherence to the Semantic Conventions ensures that telemetry data remains standardized and is easily interpretable by any compatible backend. It also reduces the cognitive burden on the end-user to reason about how the software system works, be it a first-party or third-party system.

Conventions are just conventions :)

We are long way to go towards making OTel's conventions the established norm across projects that provide their own OTel signals. Take for example HAProxy + Traefik. Each one has variable support for OTel data and require you to go through different hoops to set them up properly. On the receiving end you have to separately normalize the data of each one, in order to be able to provide a nice experience for a user who might be interested in finding, eg. all access logs for everything serving http.

Since this is an OTel-related submission, you could also use OTel collectors to collect and forward logs to a central OTel collector instance.

> yes it doesn’t solve the UI problem for those, but it does solve collecting your logs

I work for Netdata and over the last couple months, we've developed an external Netdata plugin that can ingest/index OTel logs [1]. The current implementation stores logs in systemd-compatible journal files and our visualization is effectively the same one someone would get when querying systemd journal logs [2]. i > Like… has anyone done a Jepsen-like stress test on rsyslogd and shared the results? I’ve half-assedly looked before and not been able to find anything.

I've not used rsyslogd specifically, but I don't see how you'd have any issues with the log volume you described.

[1] https://github.com/netdata/netdata/tree/master/src/crates/ne...

[2] https://learn.netdata.cloud/docs/logs/systemd-journal-logs/s...

>> This terrified the Swift compiler engineers, they were worried that untested complier pass orders would expose untested bugs

> This would scare me too.

FWIW, I made it clear that this was also a great way to break the app :)

> They had negative nine figures of (profit).

FTFY