| 13 Feb 2024 |
 edef | In reply to @zimbatm:numtide.com
the TL;DR is that if you do chunk deduplication, then recent objects might have chunks stored in Glacier. And Glacier retrieval is super expensive. yes, the answer is to just dupe the chunks in that case | 15:04:56 |
| edef | the goal isn't "store every chunk exactly once", that's not an inherent requirement | 15:09:57 |
 flokli | Well, and it only matters if you need to navigate the AWS pricing landscape | 15:10:40 |
| flokli | If we self-host the binary cache, we probably won't add our own billing department | 15:11:04 |
| edef | In reply to @artemist:mildlyfunctional.gay
On the topic of attic, are there places people suggest hosting the backing objects? I've been using b2 but find it very unreliable and slow yeah backblaze is absolute clown shoes, it just be like that | 15:11:20 |
| edef | In reply to @flokli:matrix.org
If we self-host the binary cache, we probably won't add our own billing department i'm afraid disk iops are still finite resources no matter how you slice it | 15:11:44 |
 Julien | In reply to @flokli:matrix.org
If we self-host the binary cache, we probably won't add our own billing department Is this on the table you think ? | 15:12:36 |
| flokli | Ack, but I don't think the disk iops will be the problem, the actual traffic we egress from the bucket is fairly slim | 15:12:44 |
| edef | like, deeply depends what our SLOs are here ofc | 15:12:47 |
 raitobezarius | In reply to @flokli:matrix.org
Ack, but I don't think the disk iops will be the problem, the actual traffic we egress from the bucket is fairly slim 80TB/mo if my memory serve me well | 15:13:13 |
| edef | how much we want to rely on Fastly as frontend cache etc | 15:13:17 |
| raitobezarius | In reply to @flokli:matrix.org
Ack, but I don't think the disk iops will be the problem, the actual traffic we egress from the bucket is fairly slim * 60(80TB/mo if my memory serve me well | 15:13:20 |
| raitobezarius | * 60-80TB/mo if my memory serve me well | 15:13:22 |
| flokli | For now I don't think we can solve both problems, let's solve the bucket problem first | 15:14:01 |
| flokli | Propagating some metadata, and being a bit smarter with the traffic at the CDN level is also something we can tackle, but that requires smarter clients | 15:14:38 |
| 14 Feb 2024 |
| edef | so: flipside to Backblaze | 10:27:55 |
| edef | they'll cover our egress costs if we commit to them, and they are vastly cheaper https://twitter.com/JakeDChampion/status/1757508820689973627 | 10:28:08 |
| edef | and we get free bandwidth to Fastly | 10:28:26 |
| edef | $36k/yr = $3k/mo, and no more bandwidth charges | 10:28:46 |
| 15 Feb 2024 |
 hexa | I have four remote builders. Is there a simple way to have them share their store between each other for substitutiion? | 03:48:49 |
 Jonas Chevalier | https://github.com/cid-chan/peerix maybe? I haven't tested it out yet | 09:08:38 |
| Jonas Chevalier | or setup https://github.com/nix-community/harmonia on each node and configure the caches if they are static? | 09:10:28 |
 @linus:schreibt.jetzt | In reply to @hexa:lossy.network
I have four remote builders. Is there a simple way to have them share their store between each other for substitutiion? I think adding the others to substituters as ssh-ng stores would work, but I'm not sure how well (might perform terribly) | 11:53:30 |
| hexa | thanks! peerix sounds like the simplest solution, if it (still) works? | 12:03:38 |
| hexa | * thanks! peerix sounds like the simplest solution, if it (still) works. | 12:03:40 |
| hexa | but seems to suffer from timeouts | 12:04:42 |
|  a-kenji joined the room. | 19:15:09 |
| 19 Feb 2024 |
|  rhizomes joined the room. | 04:28:19 |
| 20 Feb 2024 |
|  Sofie changed their display name from Sofi to Sofie. | 07:39:16 |
| Sofie changed their profile picture. | 14:39:13 |
