* BRIN indexes are great for append only with an incremental value (a 50MB instead of 100GB index in timeseries data in my case)
* If your disks are ssd and scsi in different volumes, adapt the random cost of io in the config to let the planner now
* if you have RAID controller and a Battery-Backed Write Cache (BBWC), you can disable Linux filesystem write barriers. removing excessive fsync from the mouth of the psql demigod in SoCaL ~linux 2015, Bruce Momjian IIRC
* monitor disk usage, in backups pipe to gz, never to disk
* counter-intuitevely modern hardware may have an io bottleneck and plenty of cpu, so try Filesystems like ZFS using Zstandard (zstd), for boost in your Transactions per second
* if possible, schema multitenancy instead of database multitenancy, instagram talked about this decades ago
* indexes index functions results too, precompute those fields and partial indexes help a lot
* BM25 and FTS in pg are so good you probably don't need Elasticsearch and you will save a lot in de-sync between both of them
* you may be hacked in this brave new world post Mythos, thus, learn PITR to an external only write, no override medium like S3
To be clear, I am not agreeing that people only upvote their favorite billionaires, just that if this particular thing was done by a Chinese model it would not have gotten the same attention
We are a core team of about 10 researchers and developers working full time on work that applies to all of the scrolls. We also ahve 4 full time annotators that tend to work on one scroll at a time. The amount of time spent on any given scroll varies with how difficult and large it is.
There is an extremely large overlap between a lot of the work we do with medical imaging, CT scanning, XRay technology, and such. A lot of the ML models and frameworks we have used and adapted for our purposes originated in the medical field for things like cancer detection or segmenting different body parts.
wanted sovereignty, bought a Blackwell for usd12k, discovered a billing issue in some customer and explains that will cover the card
I don't follow how it supports the decision of buying the card, I would even say using online SOTA models would had caught it earlier without usd12k and monthly electricity being spent
Author here. Thanks for the question. I'll answer assuming this is a question you have for me.
As explained in the post - the 3090s were what were the test bed that proved the investment was worth it. Customer support, architecture reviews, telemetry to check license compliance. None of that could be done with online models. The amount of time we can spend going backwards and forth with enterprise customers over email can really amplify costs to our team. A few actual issues we found and fixed were listed on the linked blog post: https://www.openfaas.com/blog/painless-support-with-diag/
Having recovered revenue using it in an airgap, to preserve data agreements was more of a cherry on the cake. No need to worry about the investment, it's covered itself.
Wow. Lede well buried. I thought I got the story, but after a while I started scanning over all the edge and missed that actual story. I really though we were complaining about spending $5 to retrieve data that had been stored for years at no cost.
Pretty seedy move. That, and what appears to be the dark pattern of prompting for payment first, then ultimately allowing export after refusal.
Agreed! I'd (sadly) pay more than $5 to recover some childhood memories that some services have deleted instead. Not $5/mo, though (I hate that part too).
* If your disks are ssd and scsi in different volumes, adapt the random cost of io in the config to let the planner now
* if you have RAID controller and a Battery-Backed Write Cache (BBWC), you can disable Linux filesystem write barriers. removing excessive fsync from the mouth of the psql demigod in SoCaL ~linux 2015, Bruce Momjian IIRC
* monitor disk usage, in backups pipe to gz, never to disk
* counter-intuitevely modern hardware may have an io bottleneck and plenty of cpu, so try Filesystems like ZFS using Zstandard (zstd), for boost in your Transactions per second
* if possible, schema multitenancy instead of database multitenancy, instagram talked about this decades ago
* indexes index functions results too, precompute those fields and partial indexes help a lot
* BM25 and FTS in pg are so good you probably don't need Elasticsearch and you will save a lot in de-sync between both of them
* you may be hacked in this brave new world post Mythos, thus, learn PITR to an external only write, no override medium like S3
reply