Unapologetically Catholic. Husband and Father. Infrastructure/Automation Consultant, Professional Troubleshooter, Lover of all things self-hosted!
Joined August 2012
- Tweets642
- Following235
- Followers84
- Likes644
Had a great time teaching an introductory class on DevOps for Founders going through Taylor McLemore's Ignite program with launchpadtv.com/
Goose retweeted
One-click vault deposits from 80+ chains, no bridging. Big unlock from @chainlink CCIP, and Mezzanine is glad to be part of it.
I think that is possible to get burned out, but I think humans are way more resilient than we sometimes give ourselves credit for.
Goose retweeted
Every strategy in Mezzanine gets its own vault; a loss in one vault stays in that vault.
Inside each vault, you choose your seat. Junior, if you want leveraged exposure to the yield. Senior, if you want a buffer in front of you that takes first loss.
First up is Prime Loop, with more vaults following in quick succession.
You pick the strategy. You pick your seat.
Goose retweeted
Most vault strategies are built on protocols you could use directly. So why use a vault?
“Because you can earn yield” only gets us so far. You could earn yield without one.
A vault needs to earn its place between you and the strategy. What does it take off your hands? What decisions are you handing over? And what does that service cost?
Being able to run a strategy yourself doesn’t mean you want to keep managing it.
The vault should be able to explain what it makes easier.
Goose retweeted
A vault can be a good choice for someone else and still be wrong for you.
That’s the reason for moving beyond one vault at Mezzanine. More strategies to choose from, with different exposures and terms. Within each vault, tranches give you another choice in how yield and losses are shared.
You shouldn’t have to learn a whole new process every time. The deposit flow stays familiar as the options grow.
And choosing one vault doesn’t sign you up for the next. New vaults have their own capital. You decide whether to put yours in.
We don’t expect every depositor to want every vault. We’re building out the range so more people can find one they actually want.
Power outage fried my power supply on one of my virtualization servers.
Any recommendations on non rack mounted UPS that are not going to break the bank?
Goose retweeted
There are two distinct ways a junior tranche can end up earning more than the underlying asset does.
The split is the first one. A premium goes only to the tranche taking losses first, spread across less capital than the base reward is. When junior is small, that premium lands on very little capital, which can have a multiplying effect on the rate.
The second depends on what the strategy is doing. Some are already amplifying the underlying before it's tranched, a loop is the obvious case, borrowing against a position to hold more of it, but it's not the only shape that does this.
Where a strategy like that gets tranched, both effects are running on the same book. One amplifies the underlying. The other concentrates how much of it lands on the junior.
The trade-off: Junior is first in line if it goes wrong.
Yesterday afternoon, I was taking my son home from choir practice.
We had been discussing a game he built on scratch.
He said he likes how well it works and the object of the game, but it's possible to cheat the game really easily.
So we spent 5 or 10 minutes discussing how he could fix the cheating bug in his software.
I didn't realize until later how awesome that conversation was. He's 11 and I'm starting to get a glimpse into how his mind works.
Ok, I'm picking up the local AI torch again this week. It's been a couple of months since testing local models with agentic workflows and coding tasks.
A couple of personal findings (though I suspect you've all already figured these out):
1: This configuration in my systemd service for ollama `Environment="OLLAMA_KV_CACHE_TYPE=q8_0"` has allowed me to nearly double my KV cache giving me a lot more wiggle room on an RTX 3090 24gb RAM system before spilling over into system memory. It's not turboquant, but it's a similar idea (really looking forward to seeing turboquant in llama.cpp)
2: After hanging witih Monty Craig with Sigma5C , I realized I've been placing way to much emphasis on speed, realizing that letting things run in the background (especially for side projects and local services) means I don't have run models and kv cache completely in RAM, which was a constraint I had given myself. Thanks Monty!
What models are you guys running on the RTX 3090 and for what workloads?
#AI #llm #turboquant
I had an awesome meeting with Joseph Valentic yesterday. It was refreshing to pray at the beginning and end of the meeting and to hear his story about bringing Jesus into the process of being an entrepreneur.
It is time for all of us, (me included), to bring Jesus into our process more. He should be a co-founder and the top visionary speaking through the work that we as entrepreneurs are doing.
Thanks, Joe!
This is a new one.
Was trying to install a package on NixOS, using the Official NixOS wiki.
Package was building from source, fine.
Build required tests at the end, fine.
Tests hung at the end 29/30, problem.. (I should say they didn't complete after 300 mintues)
I turned to AI and web searches. After some back and forth AI seemed to be concerned about giving medical advice during this troubleshooting step. 😁
So now I'm going to have to take my machine to my GP to get it diagnosed.
Yet another reason why you as an engineer should be reviewing what's happening in your code and what the AI's output is.
Today I was working on a ticket for a DNS monitoring script. The script assumes Cloudflare is the registrar and DNS provider.
Ok, so AI was helping me through this, and we got to the point where we needed to determine how to log the DNS records that were proxied by Cloudflare. Since the goal was to alert on dns changes, and Cloudflare proxied records don't change from the external perspective if a proxied record value changes, one could make a change to a dns record and the external monitor would not be able to see it.
AI's solution (had I not intervened or read the output noticing a bad choice) would have been to only alert on the change in "proxy" status or "grey" cloud vs "orange" cloud. This means that not only would we not see changes to the records that we control, but we also wouldn't see the change in the values of Cloudflare's proxy records either. It didn't flag this except to show its reasoning and then make the change (a quick text output on the command line that I might've missed had I not been reviewing the comments). It didn't try to find other alternatives or better solutions. It just assumed the limitation and built.
Ok, so what's the point? Well the whole point of building out a dns monitoring script, is to be able to externally monitor if something changes that you weren't expecting, alert on it, and then whoever receives the alert can take action should they need to. In this case, AI decided that the solution was to alert/log the only thing visible from the outside public internet, built it, and then said it was finished. Had I not properly reviewed what it was doing and questioned it's decisions, it would have shipped a functional script that basically alerted on a very narrow part of the attack surface.
I know there are countless wins for AI and countless stories of what I'm trying to demonstrate which is that you should make sure to review what your AI does. So I add my experiences to the list, should somebody see it and slow down, and pay attention.
Oh, and what did we build instead? A change counter. Something that instead of reporting on changes to public records that don't necessarily actually demonstrate meaningful changes to the infrastrucutre, we created a change counter that measures external and internal changes to DNS as well as a change to the token. This counter is only clearable through a code change. So instead of a noop on a DNS change behind the Cloudflare proxy, we get an actually latched alert that we can tie to a Grafana dashboard that gives us a real "something's up" indicator when anything in our DNS system changes.
Moral of the story, review your AI's output. Don't just let it cook.
Goose retweeted
Every new vault doesn't mean starting over. The infrastructure is already built and audited.
Morpho works the same way. The core is audited once, and hundreds of markets have launched on top of it as configurations, not new builds. That's how a protocol ships at pace without cutting corners on the thing everything else sits on.
I've made a non-negotiable for myself with regard to AI tools.
I will never let it communicate to other humans for me.
But there's prudence and nuance to this decision I hadn't thought about. Where's the line to draw? Is a blog post that nobody reads, considered human communication? Is the documentation in my code considered human communication?
One thing is for certain, I pretty much always get a bad taste in my mouth when I see people posting AI generated copy.
Where's your line?
Went to an IT Job Market presentation on Friday by @TEKsystems
Mostly confirmed what we are all seeing in the job market
Two things stood out to me.
1: Fully remote work is dying (will probably never completely die but there is a real expectation that people show up to a physical location at least part of the week)
2: The pendulum is swinging to the generalist. So if you are moderately adept on a broad range of skills that go beyond your normal vertical, you should probably find a way of showcasing that.
I'm not sure how I'm going to demonstrate number 2 yet, but I've always considered myself a jack of all trades in the pursuit of being a master of all trades. 😁