00:04:47 that doesn't matter here, as htop isn't a suid executable and shouldn't be 01:07:54 suid binaries can be owned by any user, and when they're run they run with the effective user id of the user who owns the binary, and the real user id of the actual user running the binary. Tools like su and sudo are well known to use them, so the binary runs as root, and then calls setuid or similar syscalls to change the effective user id to 01:07:54 another user and then calls execvpe or similar. scoobybejesus. 01:08:39 https://lounge.swee.codes/uploads/77a0a2b8220da29d/image.png i am now one of the few people who run KDE on freebsd 01:08:51 Congrats 01:54:23 Congratulations on the KDE running. (Not for me but ykinmkbykiok. :-) 02:08:09 rwp: https://paste.debian.net/hidden/d3a54f9f 02:08:14 swee: congrats! 02:17:29 how do I stop KDE Plasma from freezing (until I CTRL+ALT+F10) when I press Alt+F4? 04:59:52 yay i even got audio working on my setup, was really weird it wasn't properly autodetecting the headphone jack and speaker in my optiplex 05:00:04 but hey it works 12:27:37 hm, three edits (and with that emails), just because I wanted to add an attachment to a bug, change its title and reopen it… 14:11:16 rwp: sure, i was just pointing out why they got a different error that time 14:30:07 hello, it seems the DISTRIBUTIONS setting in our installerconfig is no longer honoured in freebsd 15.0. is there some way to work around this? 14:31:42 rather, it seems to always be set to "base.txz kernel.txz" 14:40:04 the bsdinstall man page says DISTRIBUTIONS defaults to empty which doesn't seem to be true 18:19:11 dch: Hey, you ever got anywhere with those viamillipede problems? :) 19:55:14 kevans, :-) 20:49:22 Why is my zfs recv stuck in "zfs 23871 [q->bq_pop_cv]" when the zfs send is already done (has printed its summary line)? 21:13:46 Ltning, is this over shell pipe? ssh? netcat? 21:14:10 netcat in this case, for simplicity 21:14:14 I thought so 21:14:28 Looks like removing some of the options to zfs send fixes it 21:14:29 then it's probably keeping the connection open from the other side 21:14:32 Trying to bisect now 21:15:11 nc is bidirectional, and both sides need to explicitly close the file, or they will not terminate, even if you don't want to send anything in the other direction 21:15:55 It works fine without '-wceLV' on zfs send 21:16:08 I've used nc for this a million times, this is the first time I see it 21:16:16 source is 14.2, destination is 15.0 21:16:28 Hmm. That is strange. I usually invoce something like nc -Nl 4446 on the recv side 21:16:46 4446 is an example port obviously 21:17:58 maybe I'm misdiagnosing your issue then, sorry 21:21:54 I think -w already implies -Lec, so, -V is the suspicious one... does it work if you leave out -V, and keep the rest? 21:26:04 It completed when I removed -L 21:26:28 Which sort of rings with https://github.com/openzfs/zfs/commit/577d41d3b2e4b37f51270c399c85b2708e21238a - "zfs recv hangs if max recordsize is less than received recordsize" 21:27:51 Ah, that's a much more interesting find... thanks for letting me know 21:33:44 Hrm, no, that was a fluke apparently