Owner-Operator::Risk-Inheritor

Fun aspect of building and maintaining my own website stack is that I own the security and maintenance cycle of my system. Classic problem with avoiding frameworks is I now own all of the mundane, framework-decisions I otherwise wouldn't make with something like Laravel. "How am I going to defend against XSS Attacks?" "Why do I care about Cookies?" I spend a fair amount of time doing my own due diligence after having built everything!

Part of the problem with the web prior to ~2023 is that figuring this stuff out meant knowing how to ask about them specifically. You needed to know there was such a thing as CSRF policy, and that there were people out using these things called iframes that can be used to spoof your site. Anyway, I spent the last week or so learning these things and figuring out how and why certain security headers exist haha!

If anything breaks really crazy it's because my content policies have shifted pretty aggressively. You have been warned.

Open Source is For Losers

Inflammatory header aside, it's pretty clear that, at least in terms of LLMs at the frontier, you only open source the model weights if you are behind the frontier as a mechanism of catching up and eating some of the margin. If you are actually at the bleeding edge, then the weights are your edge, and giving that away is, well, clearly bad game theory.

Don't get me wrong, I love open source, but it just seems generally true that if your code isn't winning out in terms of private capex then you can gain margin by making your software available to a market that won't want to otherwise use proprietary software for reasons the proprietary software cannot or will not support.

Nobody uses open source discord alternatives, comparitively speaking. Nobody uses claude code alternatives, comparitively speaking. If your product is good, your competition simply has to take up the market share you aren't willing to take. They lost, hence OSS.

Eulogy for a Bunny

A year ago almost to the day we brought in an old, grumpy little bunny named Bugs. His family no longer could take care of him, and my Wife's boss asked if she would be willing. We obliged and it has been a wonderful journey. Bugs Bunny was there for both the passing of my father and my grandmother, and he gave us comfort throughout all of it in his own, grumpy, old-man ways.

He was a quiet creature, who enjoyed carrots, grasses, his grass pellets (he loved his grass pellets), little flowers from the yard, and peeing in his water dish. I have learned way more about bunnies than I ever thought I would, and his presence was warm through a really tough winter.

It's not fair that life keeps taking from us, and my heart is broken even though he was a small creature. Bugs I hope your life was full and we did right by you, I'm sorry for the silly jokes and being grumpy having to clean out your crate. You will always have a place in our hearts, and we thank you for being with us in these dark years.

God bless those furry little creatures, your creation, for they are Good.

K3 or Bust

Moonshot announced Kimi K3 (Obligatory Seagull) and I can't help but feel generally underwhelmed of late by open and closed source model releases. There just isn't particularly much worth discussing these days outside of the cost matrix.

Kimi represents another step along that grinding exponential, but it just gets harder and harder to qualify models for daily work unless they get cheaper per quality token output. Until I can see Opus 4.6 quality at Deepseek v4 Flash speeds and prices it's just not really worth concerning myself with the circus.

Don't get me wrong, I am more amped than ever about large language models, I just see very little in the way of meaningful work being done in the architecture itself. There's so much room left in harness technology and orchestration strategies left incomplete I find discussing TPUs and Novel Decoding strategies at scale to be mostly marketing noise.

"Adding More Compute will compensate" doesn't mean anything when I can't afford to use the current generation of models and all of the older models have been deprecated and delisted.

Measure Or Perish

Been outside of engineering-land and in computer-science land as of late. Been spending a lot of time investigating some different data-warehousing patterns for a project at work, it's been a fascinating look into the difference between engineering problems and running actual scientific inquiries into a problem. Engineering is so often concerned with constraints and implementation concerns because most problems have fairly well-established solutions within the computer science field. But at a certain point with engineering you run into problems that require a detailed and scientific inquiry that leads you by first principles into territory you, the engineer, were unfamiliar with.

I have to avoid speaking about specifics due to NDA concerns, but the problem involves a flattened

.bak

file holding proprietary data dumped from a vendor. Our client wants us to host some partition of this data, which we pull from an SFTP transaction. The problem is that Microsoft SQL Server has to run the decryption on this data, and then we need to translate this data to our application surface. We don't use MSSQL in our application, so our plan is to read from a remote RDS instance in AWS which can host an ephemeral image of the .bak file.

If any reader is familiar with massive data transfers, they'll start to piece together the solution, but if you are not familiar with data warehousing you might start out naively reading tens of millions of records from your RDS instance into a postgres instance, performing ETL while holding the RDS connection open, and finding out you've spent 40 minutes synchronously writing data from one to the other in a process that is supposed to become an hourly dump. Hahaha! By my estimates this implementation would have cost us well over a thousand dollars a month to run!

Where engineering is concerned with this is relating to the process of how to efficiently perform this operation in a fraction of this naive implementation's runtime, but it is the process of Computer Science which ultimately leads the engineer to his solution. having spent the better part of the last two days, I've managed to derive "sophisticated" Transient Storage Techniques for Data Lakes: literally just dumping the MSSQL data out to .tsv files in an s3 bucket for asynchronous writes to my application warehouse database. Sometimes you spend hours chasing parallelism, batch-write techniques, microsecond differences between INSERT and COPY, and ultimately realize the bonehead implementation is the fastest, cheapest, and most-integral!

And the Novice Data Technician (me) can really only arrive at this conclusion via research and metrics. It Is By Measurement We Live And Die!