Meh. This is just structured logging with some post processing. You can definitely derive metrics and traces based on them, but doing so is more expensive in many ways.
84 karma · joined November 10, 2015
This guy is totally correct. We also used Go for everything -- as it was hot stuff at the time -- and also very frustrating to deal with early version. Dependency management nightmares, bugs in the runtime, etc.
He also had to have a C shim that got loaded first, or shelled out to.
The hype around Google tools was pretty fascinating. I felt like that was the primary reason around using such an immature language at the time. There were better systems languages around for that kind of work.
I have found that Gemini often claims it did something, but didn't actually complete the task.
I just had 3.8 Flash do a major refactor -- that never should have needed to be done in the first place -- and switched to Argon 4, and had it review it.
Almost everything had been stubbed out by 3.8, and none of it was properly integrated into the codebase. :facepalm:
I setup https://github.com/schancel/software-factory as an interim process for how I work. It burns through tokens quite quickly -- but it gets work done with minimal intervention from me. The skills create tickets, dependencies, spawn agents in parallel where possible -- manage claims through 1 github account on tickets to track which agent is working on what; and provide contexts where agents need to restart or change models.
It hypothetically right-sizes tickets for sending various items to right-sized models if you use the latest frontier models as a coordinator.
But again, still iterating as I find issues.
But, instead, we end up with 1 passkey per device (potentially per web browser) per website -- and some websites do not allow any other kind of auth. If you lose that phone, or wipe it, move on, or it is compromised, now you can't login to your account anymore?
There is literally no reason for all of this nonsense.
Websites should be providing a challenge, your device should produce a tweaked key based on the domain, sign the challenge, and that should be it. You have one root key per device.
A standard API to register new passkeys for new devices.
Require two factors Password + passkey, or two passkeys.
No transferring private keys between devices.
Requiring 2 factors per website per user, potentially per device, is far more complexity than most people are capable of dealing with.
And I really do not like that my phone# and email# are now de-facto second factors on everything.
I find myself having to check the work much more. It takes quite a few liberties with procedures I wanted it to follow.
The security team wouldn't budge things up to 1 day even.
When you have 2 or 3 factors on every tool -- even things like prometheus. It gets excessive.
I think nats is a great technology for a number of use cases. It's unfortunate that it's so hard to find the resources to support and maintain open source software while paying developer salaries.
Derek put a ton of work, effort, and money into NATS.
It's a sad story to me; I don't know what the answer is to these sorts of "tragedy of the commons" type issues are.
I'm working with some people to build out Stamp which is federated in a similar way to XMPP but attaches small cryptopayments to keep undue about of spam off the network.
Take a look: https://www.stampchat.io/whitepaper.pdf
Stamp is pay-to-post, and the proceeds go back to the entire community.
Some people have been working on an interesting solution called StampChat which has a similar topology to email, but the messages are encrypted by default and the spam mitigation is done via sending tokens to the recipient (ala Hal Finney's RPoW) idea.
It's still a prototype, but there is one deployment over here: https://web.stampchat.io
The whitepaper on the protocol is here: https://www.stampchat.io/whitepaper.pdf
There's a faucet here if anyone is interested https://faucet.lotuslounge.org/
We're not doing an ICO or anything, happy to give out more tokens out.