12:17:48 <yourfate> the ecc ram in my home server cost me 371€, its 3330€ right now. Its 2x 32GB ddr-5 edd udimm
12:17:58 <yourfate> *ecc
12:19:15 <yourfate> I know that udimm-ecc is kinda rare
12:19:34 <yourfate> as most real server boards use rdimm, and consumers usually don't run ecc
12:42:16 <ketas> now they will start iirc
12:42:36 <ketas> density is so high that ecc is requires
12:42:37 <ketas> d
12:47:29 <yourfate> I mean, they have this built-in pseudo-ecc already
13:00:55 <ketas> wannabe ecc
13:01:05 <ketas> memory girls
13:01:20 <ketas> which pseudoecc tho?
13:06:41 <ketas> DDR5 on-die ECC detects and corrects one-bit errors. It cannot detect two-bit errors, so it will miscorrect some of them into three-bit errors.
13:06:47 <ketas> hmm
13:07:22 <ketas> it's a error making code?
14:01:30 <yourfate> that's why my server has "proper" ecc ddr5
14:01:40 <yourfate> at the time it was not prohibitively expensive
14:01:48 <yourfate> should have bought 128gb
14:18:23 <moviuro> dch: after looking some more into mtree(8), it's... kind of janky? It errors for permission mismatches or links not complying with the spec; but it doesn't return an error code when files from the spec are missing? It also won't return an error code with -U even if files are (still) missing or have a bad cksum (the manpage reads: -U Same as -u except that a mismatch is not considered to be an
14:18:25 <moviuro> error **if it was corrected.** -- mtree(8) doesn't have the means to fix broken files)
19:35:44 <wavefunction> I managed to acquire a dell workstation with 128GB ecc memory. I thought "eh, if I need 256GB that's only a few hundred $ USD"
19:36:43 <wavefunction> https://www.gluecode.net/blog/2023/11/29/newhardware.html Amazing what a difference three years makes in this bull**** economy
20:41:20 <wavefunction> hnghngh My 4TB drive I was going to buy was < $200 at the time. Now it's $640 USD.
20:45:58 <gbon121> hey, is it right that packagesite.pkg and data.pkg in https://pkg.freebsd.org/FreeBSD:14:amd64/quarterly are over 1GB total?
21:04:16 <wavefunction> FreeBSD 15 is ~11mb for each file. FreeBSD 14 is ~565mb. That seems... not correct.
21:04:33 <wavefunction> Then again, 14 has a bunch of quarterly and release folders.
21:05:52 <gbon121> I'm pretty sure 14 was around 10 MB last time I checked it, a few hours ago
21:09:05 <zi> that seems fucked
21:09:06 <zi> looking
21:09:25 <mason> Accumulation of historical data?
21:09:33 <mason> That'd be a fairly same explanation anyway.
21:09:45 <mason> sane
21:11:26 <zi> accumulation of uhohs
21:59:00 <thresh> Hi.  I'm experincing a weird issue with pkg on FreeBSD 14.4/amd64 on AWS.  `pkg update` takes ages, spending most of the time in Processing entries.  `pkg install` then fails with "Failed writing received data to disk/application".
21:59:20 <zi> thresh: known issue.  fix is in progress
21:59:36 <thresh> oh thanks
22:04:25 <dvl> I see I've broke sysutils/msktutil, and I don't see how to make it happy again: https://gist.github.com/dlangille/c1a8029eb70f7b377f2b218b98e4975f