we have a "release" branch and a "develop" branch. The release is trunked on the last released version and (in theory) only gets fixes. If we need to fix a more older version, we create a temporary branch on that version to fix it, and we cherry pick the fixes (or merge to) to release branch and then to develop branch.
The triple mortal loop, comes that we have two versions of the product. One with the old no responsive frontend and other with a modern responsive frontend. And we need to release and develop the two versions for sometime, before the direction decides to kill the old no responsive version. So we end with 4 branches: release, release_rwd, develop and develop_rwd. If we fix something in release, we need to do a diamond merge : release to release_rwd, release to develop, release_rwd to develop_rwd and develop to develop_rwd
And nobody talks that the "20 bucks per worker" it's selling it at loss. I'm waiting to see when they put a price that expects to generate some net income...
They are not similar. A LLM is a complex statistical machine. A brain is a highly complex neural network. A brain, is more similar the perceptron of some AMD CPUs that to a LLM.
I would always prefer something local. By definition it's more secure, as you are not sending your code on the wire to a third party server, and hope that they comply with the "We will not train our models with your data".
That's a fair point - you're talking about data security (not sending code to third parties) and I was talking about output quality security (what the model generates). Two different dimensions of "secure" and honestly both matter.
For side projects I'd probably agree with you. For anything touching production with customer data, I want both - local execution AND a model that won't silently produce insecure patterns.
Oh it absolutely does, never said otherwise. Hosted models produce plenty of insecure code too - the Moltbook thing from like a week ago was Claude Opus and it still shipped with wide open auth.
My point was narrower than it came across: when you swap from a bigger model to a smaller local one mid-session, you lose whatever safety checks the bigger one happened to catch. Not that the bigger one catches everything - clearly it doesn't.
why stopping at rust? Let's have a windows version written in python another in crystal and another in java. At least the generated code will be readable and maintainable!!!/s
I saw 555 being used to implement the "Turbo" buttons in these old 8-bit pads for NES clones and similar.
Also, I think that the mythic Gravis game pad uses a 555 to implement the same function when it is in two button mode.
Omg... and thinking that my mother throws a huge stash of components like that. my father was an electrical engineer and ham radio. At least, I managed to save a stash of electronic valves and some analog equipment like an old oscilloscope that could be in a museum (I saw a similar model in a museum).
I've tried it several times, and it's not for me. I want my spreadsheet program to have a UI and UX that's polished for the idiomatic standards of the platforms (macOS and iPadOS) I'm running it on.
The triple mortal loop, comes that we have two versions of the product. One with the old no responsive frontend and other with a modern responsive frontend. And we need to release and develop the two versions for sometime, before the direction decides to kill the old no responsive version. So we end with 4 branches: release, release_rwd, develop and develop_rwd. If we fix something in release, we need to do a diamond merge : release to release_rwd, release to develop, release_rwd to develop_rwd and develop to develop_rwd
reply