that doesn't matter here, as htop isn't a suid executable and shouldn't be

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

another user and then calls execvpe or similar. scoobybejesus.

lounge.swee.codes/uploads/77a0a2b8220da29d/image.png i am now one of the few people who run KDE on freebsd

Congrats

Congratulations on the KDE running. (Not for me but ykinmkbykiok. :-)

rwp: paste.debian.net/hidden/d3a54f9f

swee: congrats!

how do I stop KDE Plasma from freezing (until I CTRL+ALT+F10) when I press Alt+F4?

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

but hey it works

hm, three edits (and with that emails), just because I wanted to add an attachment to a bug, change its title and reopen it…

rwp: sure, i was just pointing out why they got a different error that time

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?

rather, it seems to always be set to "base.txz kernel.txz"

the bsdinstall man page says DISTRIBUTIONS defaults to empty which doesn't seem to be true

dch: Hey, you ever got anywhere with those viamillipede problems? :)

kevans, :-)

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)?

Ltning, is this over shell pipe? ssh? netcat?

netcat in this case, for simplicity

I thought so

Looks like removing some of the options to zfs send fixes it

then it's probably keeping the connection open from the other side

Trying to bisect now

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

It works fine without '-wceLV' on zfs send

I've used nc for this a million times, this is the first time I see it

source is 14.2, destination is 15.0

Hmm. That is strange. I usually invoce something like nc -Nl 4446 </dev/null to explicitly send an EOF

on the recv side

4446 is an example port obviously

maybe I'm misdiagnosing your issue then, sorry

I think -w already implies -Lec, so, -V is the suspicious one... does it work if you leave out -V, and keep the rest?

It completed when I removed -L

Which sort of rings with openzfs/zfs 577d41d - "zfs recv hangs if max recordsize is less than received recordsize"

Ah, that's a much more interesting find... thanks for letting me know

Hrm, no, that was a fluke apparently