googletron

It’s simply not understanding. In terms of latency, LLM processing for large fact-based decision-making was incredibly slow. The real unlock here was speed in decision-making.

yeah grinding on side projects, while everything is in flames.

this is fine.

you can see the diff before you merge it. my main use case for lg is looking at diff and staging logical parts then committing with another tool or manually.

what?

what love to hear more about how people are using agents to build useful things.

This is the feature, I want.

Nice! Are the plans to move upstream into voice chat or recording software for demos?

Thank you.

Thanks for sharing the post! Would love feedback on the work and post!

I challenge you!

By writing and editing.

I was a big fan, growing up. Screensavers etc. I haven't kept up as much since, but he was a big reason, I got into computers as a kid. Big up Leo.

yeah just grab a cheap external microphone, it will do the trick! Keep up the awesome work.

Very cool project! I wanted to listen to your video, but the microphone noise was too much.

I hope you do a walk through of the code for this.

I have written something about this which says SOA is quite the middle ground. https://architecturenotes.co/granularity-of-systems/

That’s fair feedback. Large screen at home. I will try and resize them. Thanks!

I totally agree with this.

Thought it might be cool to take a pass on 12 Factor application and how its evolved since it first came out!

I would ensure that the data size is managed if you hit the limits due to your policy Redis will stop responding to ensure the data it has isn’t lost. I would also turn on some sort of persistence for data recovery in case of catastrophic failure. Early on this is totally fine and I would setup some monitors in redis data size relative to memory and try to keep 20% overhead weird things start to happen when systems are memory constrained.

> understanding the big-O complexity of each operation (…and ensuring that none of your interactions are more than logarithmic).

This is a good idea, maybe a prompt for another post.

Fair point! Will update! I think the focus was on pure line latency. Check out the more detailed post here. https://gist.github.com/jboner/2841832

Its hand drawn with some fonts for the titles.

My personal nightmare happened and accidentally published a rough draft! It has since been updated! Apologies!

I wrote a little post on how Redis works and its various setups! How does everyone setup Redis? Elasticache is a good answer too :P

I write architecturenotes.co for this specific reason. Check it out.

Small plug for what I am working on https://architecturenotes.co which is designed to help with that you are try to learn.

You are absolutely right about the C being more inline with CAP one.

I have a post in draft to discuss disk trade offs which digs into this aspect, its impossible to dig into everything in this level of a post.

Good point. Its often the problem space and other constraints that usually drive these decisions. Its important that you deal with problems when you have them.

I would love the feedback, what was questionable? striking the balance is tough. jepsen's content is great.

Great resource! I have it linked as a reference!