| 27 Jul 2025 |
 Sergei Zimmerman (xokdvium) | In reply to @emilazy:matrix.org
well it's on the physical package. maybe someone has been wild enough to try and replace just the memory https://forums.macrumors.com/threads/m1-m2-m3-macs-user-memory-upgrades-by-soldering-blocked-by-apple.2410451/ | 19:05:11 |
 emily | the RAM one looks like an Intel Mac | 19:07:05 |
| emily | but yeah I was surprised to learn people have managed it with the NAND | 19:07:06 |
 raitobezarius | In reply to @aloisw:julia0815.de
Can someone with Darwin access then please build https://gerrit.lix.systems/c/lix/+/3778 and post one of the lix-util, lix-expr, lix-fetchers, lix-store pkg-config files? we should maybe get you a Darwin remote builder if you're interested? | 20:00:39 |
 EsperLily [she/her] | oh hey you just merged 3765 as I was reading through it. I was going to ask, why are we still copying the file when we have no chroot? don't we just need to set NIX_SSL_CERT_FILE to point at the caFile in that case? | 23:17:15 |
| EsperLily [she/her] | aaaand i just saw a bug in the new code too, so i just put a comment on it | 23:26:40 |
| 28 Jul 2025 |
 jade_ | ive also noticed this myself. i can possibly throw a no-SIP vm at the problem some day at work. what i would like to learn is what operation is slow in the derivation builder. need a consistent reasonably demanding and reasonably consistent benchmark for this. maybe a build of lix itself, idk. | 00:08:53 |
| emily | my top suspect is QoS priority inversion which a quick taskpolicy call with a non-daemon build should give at least some kind of results for | 00:09:40 |
| emily | even just comparing daemon vs. non-daemon would probably help | 00:09:44 |
| jade_ | mmmm | 00:10:12 |
| jade_ | yeah my test hypothesis is to try to do the genericBuild thing for lix derivation outside the daemon and compare | 00:10:48 |
| jade_ | I concur on your suspicion on QoS being involved, since Kate actually also mentioned this a year ago | 00:11:09 |
| jade_ | * I concur on your suspicion on QoS being involved, since Kate actually also mentioned this a year ago iirc | 00:11:14 |
| emily | if it is priority inversion with the daemon then a quick fix may be as simple as ensuring the daemon re-execs itself with the posix_spawn API to set utility QoS class | 00:12:37 |
| emily | I also suspect something about logging could be very slow | 00:12:53 |
| jade_ | is there a way to get the task policy of a job? | 00:13:01 |
| jade_ | this is DEFINITELY true | 00:13:08 |
| jade_ | the logging in lix is blocking on the daemon | 00:13:15 |
| jade_ | which is totally fucked and we can't really fix it in the current protocol, not easily at least | 00:13:33 |
| jade_ | well, maybe we could | 00:13:42 |
| jade_ | we would just have to dispatch "logging" to a separate task than "dealing with proto" | 00:14:01 |
| jade_ | but it's super fragile | 00:14:04 |
| jade_ | known perf problem :( | 00:14:23 |
| emily | not sure | 00:14:57 |
| jade_ | https://git.lix.systems/lix-project/lix/issues/717 here's the last time qos was mentioned and i filed a bug | 00:15:16 |
| jade_ | i would suspect it might be in either activity monitor, some xcode thing, or native ps | 00:15:48 |
| emily | whoever led to that bug report must be super smart :D | 00:15:51 |
| emily | I think it's not in Activity Monitor sadly | 00:16:09 |
| jade_ | sudo powermetrics --show-process-qos --samplers tasks -n 1 | head -n 30 | 00:16:12 |
| emily | https://developer.apple.com/library/archive/documentation/Performance/Conceptual/power_efficiency_guidelines_osx/PrioritizeWorkAtTheTaskLevel.html#//apple_ref/doc/uid/TP40013929-CH35-SW10 | 00:16:18 |
