But I’ve seen approaches using eBPF to collect telemetry to OTEL
1,358 karma · joined March 24, 2016
But I’ve seen approaches using eBPF to collect telemetry to OTEL
I don’t know yet if it’s a good solution. But only thinking in terms of files / filesystem sure make things easier.
Also makes branching “easier”: no handling of merging or conflicts, the receiving agent just gets N file systems and decides how to handle things.
My current vision, and prototype, is that it should be as close as possible to a "real" language as possible so that both the user and the agent know immediately how to use it and how it functions.
So for `pi` it means using typescript.
Then the UI is derived from the AST / code as much as possible and for things that aren't neatly possible like that I eventually add small semantic helpers that define the UI.
For example "plan -> execute" is:
await flow.unroll(
remaining.map(point => ({
key: point.id,
label: point.objective,
})),
async () => {
for (const point of remaining) {
await flow.item(point.id, async () =>
await flow.agent(executePoint, {
title: `Point ${point.id}`,
prompt: point.objective,
}));
}
},
{ title: `Plan r${planRevision}` },
);
( simplified code )
in my implementation and `unroll` is only there to have a nice ● Plan r1 · 1/3 · active
1. Inspect parser behavior
● 2. Add empty-input coverage
○ 3. Run focused checks
UI instead of a plain "Plan · 1/3" UI with no detail (which would happen if I just used a for loop, yes it works)M5 device are cool but they do have that, as ugly as it is useful, functional diagram printed on the back...
It probably was, at least inadvertently. Very easy to imagine that one of the post-training step (RLHF, DPO etc) reinforced the "sounds clever" behaviour.
I don’t know if LLMs will kill the working-mathematicians but at least seem like that it doesn’t seem absurd to imagine LLMs will be good at math…
If that arrogance was well placed at least you could somewhat excuse it, but the fact that it is so overtly hypocritical and based on false premises just makes it so much worse.
My (wrong?) understanding was that there was a positive correlation between how "good" a tokenizer is in terms of compression and the downstream model performance. Guess not.
Especially since it is easier to find badly underpaid (and not particularly competent) Windows sysadmins than it is to find badly underpaid Linux admins.
We don't put our transitional proofs in papers, only the final best one we have. So that analogy doesn't work.
For every proof in a paper there is probably 100 non-working / ugly sketches or just snippets of proofs that exist somewhere in a notebook or erased on a blackboard.
Context rot is very much a thing. May still be for future agents. Dumping tens/hundreds of thousand of trash tokens into context very much worsen the performance of the agent
I honestly don't know if I'm doing something very wrong or if I have a very different working style than many people, but for me "just give the prompt/session" isn't a possibility because there isn't one.
I'm probably incredibly inefficient, because even when I don't use AI it is the same, a single commit is usually many different working states / ideas / branches of things I tried and explored that have been amended / squashed.
You can litteraly "improve" your model on LMArena by just adding a bunch of emojis.
> 97 matches
Ok I'll read it :)
Pandoc is a ridiculously underrated and powerful tool but it solves a different problem. Someone still has to write typesetters ;)
I love, and hate, LaTeX and the idea of a LaTeX successor / alternative is incredibly appealing.
And the fact that they are aware that microtypography IS important and that they are working on it is a huge huge plus.
I think the position has shifted to "let's pretend this problem doesn't exist because the AI market is too big to fail"
But currently I sadly have to say the model's "help" is often a net negative.
It's really not though? Honestly I'm surprised coding agents fail hard at this task apparently