02:53:20 richlowe: FWIIW. I usually use http://iks.cs.ovgu.de/~elkner/tmp/template.sh as a starting point ... 16:47:01 hrm.. it looks like busstat only works (today) on sparc... would x86 HW have anything that might make sense to wire up to the command? 17:55:12 jbk: Kind of, maybe? 17:55:49 Right now on both Intel and AMD we really only do mostly CPU core based perf counters. 17:55:59 There are perf counters for the memory controller and data fabric. 17:56:30 that's what i was wondering... 17:56:42 sad thing is, our ehci is still not working with UTM (qemu). 17:56:56 They have a slightly different interface than the core counters. 17:57:09 So there's a bit of enablemen work we need to do. Less certain what intel currently looks like. 19:41:04 jperkin: the glib thing talked about https://mastodon.social/@ebassi/110039041635210901 here, and in something alanc mentioned I think also on mastodon too, seems like it might hit you really hard, since in your case the "system allocator" it'll now use is umem 19:41:19 which as we know, is sometimes too fussy for random code as it is. 19:41:30 (it's the right amount of fussy, random code is bad, but you know what I mean) 19:43:23 I had just boosted that post from ebassi 19:43:37 oh, maybe it was on the distribution list thing you put in #oi-dev 19:43:40 glib is linked with libumem instead of libc malloc? 19:43:53 alanc: pkgsrc uses umem as much as it possibly can 19:44:08 which doesn't sound fun for this 19:44:29 yes, there was a post in https://lore.kernel.org/distributions/ about it, which I first saw in a reply to @ebassi's and then went to look at the archives of the rest of the list 19:44:41 ah, I didn't know pkgsrc did that 19:45:19 (there are other posts in https://lore.kernel.org/distributions/ which may be of interest to other distro makers and package builders as well) 19:47:28 and I forsee lots of bugfixes by tsoome due to ancient K&R style code due to https://lore.kernel.org/distributions/2354211.7hzS34FegO@nimes/ when it's time to start porting to gcc 14/15/whenever-C23-lands 19:47:57 I've been trying to encourage people to do that now, but I keep failing. 19:48:23 similar to what https://fedoraproject.org/wiki/Changes/PortingToModernC is doing with other packages 19:48:37 the problem is that (and -Wno-implicit-function-declaration) lead you into some horrific code 19:49:39 finding people who want to fix the mess it finds is easier until they see the mess, and realize they need to test it 19:50:54 though having said that, sommerfeld, if you were looking at printf-y warnings, you might also be interested in places we add -Wno-implicit-function-declaration. Some of them are very bad. 19:51:01 yeah, I tried to make people convert K&R-> ANSI as part of all our LP64 conversions, but we've still got some left to do to 19:51:13 I specifically remember udfs being worse than very bad. 19:51:15 but there were others. 19:52:01 thought I guess the places I made them change () -> (void) in function declarations aren't needed for C23 now 20:00:44 richlowe: yeh we'll have to see what falls out, good thing that they're seeing issues on primary platforms, gives us hope they'll fix upstream 20:53:55 alanc yep (I do hope I wont be alone in this, however:D) 21:02:49 you won't, I hope 21:03:15 'cos fixing those things would help me too, as far as having faith in stuff having to all be 64bit 22:20:56 sorry to interject but what is not 64 bit these days except emulators 22:22:11 we can't even support sparc because noone has the hardware 22:37:08 most of the programs shipped in illumos 22:38:02 they still build 32-bit because Solaris & illumos used to run on 32-bit CPUs and no one has put in the work to make sure they're 64-bit clean and build them that way, even when running on a 64-bit CPU/kernel 22:39:41 my friend asks if bcantrell is still a part of this project 22:40:00 please don't ban be for asking 22:45:43 dangergrrl: We have working hardware and are keeping sparc alive in OpenIndiana with the same frequency as x86