efxhoy
implied the humans sessions could have been (and probably were, why wouldn’t they be?) in the training set?
If I was trying to make a model smarter and I had transcripts from the smartest mathematicians in the world I’d make sure the model trained on them.
The job queue runs on the cache db, scheduling jobs to move data from bigquery into postgres. It’s pretty neat.
Now we’ve run into near-real-time requirements so clickhouse is getting thrown into the mix.
It’s pretty funny the lengths we go to to implement user facing analytics that’s basically just “you are visitor number X” from 1995.
The setup on openbsd was very straightforward. I had to read up a bit and claude helped getting ipv6 and vlans up. Had I ignored ipv6 it would have been ready in half an hour from just reading man pages and official docs. The only reason ipv6 took longer is because I had no idea how it works.
I researched the equivalent setup on linux and it was much less straightforward. In openbsd I only used software in the base install. For linux there were a lot more choices to make, which for me just made setting it up more difficult. I don’t want to pick a firewall, I just want to configure the simplest possible one.
The only issue I had was the system hanging when no monitor was connected to the hdmi port. I use an old apollo lake mitac pd10ai itx board. Displayport worked fine during install but black screened before I got a shell and crashed. Tried setting some kernel options to disable some display driver without success. Opted to get a dummy hdmi plug instead for reboots without a monitor.
Sweet! I’m just about to replace pfsense with openbsd on my router. Smoothly setting up ipv6 is a bit of a headscratcher atm, mainly because i’ve never had to understand it before.
They also have “forward deployed engineers” to help organizations actually use the platform. It looked complicated enough to probably be completely useless without these specialists, even in a “self hosted” setup.
The managed hosting also seems like a major selling point so many deployments that probably should be self hosted probably aren’t because muh managed services added value.
And the backdoors of course. There is no way it isn’t full of plausibly deniable “metrics endpoints” that helpfully spew out all the internal data if the right key comes knocking. There’s no way it’s auditable at the level of detail you would need compared to the value of the data and the sophistication of the potential attacker (NSA).
By claiming our ancient predecessors had terrible taste you can make them look like primitive fools, and make our own modernity appear superior in comparison.
When boiled down to culture war brainrot the poor coloring in the reconstructions becomes a woke statement that the brutish patriarchal empires of antiquity have nothing to teach our sophisticated modern selves and that new is good and old is bad. A progressive hit-piece on muh heritage.
Anything you don’t like is a purple haired marxist if you squint hard enough.
Idk why my brain went there. I’m guessing the years of daily exposure to engagement-farming ragebait had something to do with it.
Can’t really justify it at work though, projects are too big to and gnarly keep in my head.
1. Migration that adds firstname and lastname columns will all nulls
2. Deploy application code change to start populating firstname and lastname alongside fullname, still reading fullname in the code.
3. backfill the firstname and lastname values with a script/command/migration
4. change app code to read firstname and lastname and stop writing fullname
5. drop the fullname column
My current headache is what to do with an actually big table, 25 billion rows of json, for development. It’s going to be some DBT hacks I think.
God help you if you want to unit test application code that relies on bigquery. I’m sure there are ways but I doubt they don’t hurt a lot.
I find that sublime is just smart enough to go to the definition using only its “dumb” grepping based approach.
I think the hurdles of getting a nice LSP setup that works across projects in different languages and in a polyglot monorepo is a real determinant. I just really dislike spending any time configuring my editor past the basics, because I’m lazy, updates break them, I move between machines, etc. Getting comfortable with just the basic features means I have less pain maintaining my editor. It’s not a great excuse but for me it’s the path of least resistance.
I frequently pair with colleagues, some are vscode users that are heavy on LSPs and copilot. I have one greybeard colleague who runs a very sophisticated neovim setup, and spends a lot of time maintaining it. We’re all roughly equally productive at the “writing code” part of the job. What sets us apart is our skill in actual software development, which I find is completely uncorrelated to the editor setup. We all work in the tools that are most comfortable to ourselves.