💾 Archived View for gemini.ctrl-c.club › ~phoebos › logs › kisslinux-2022-01-25.txt captured on 2024-05-12 at 16:03:27.

View Raw

More Information

⬅️ Previous capture (2022-03-01)

-=-=-=-=-=-=-

[2022-01-25T00:54:13Z] <phinxy> isnt wget nicer than curl?
[2022-01-25T00:54:59Z] <phinxy> curl -fLO ..  Am I doing it wrong?
[2022-01-25T01:06:15Z] <phinxy> wget can be typed with one hand and doesnt require -O, and is built in to busybox!  :P
[2022-01-25T01:12:37Z] <dilyn> it's far more limited tho:P
[2022-01-25T01:36:28Z] <acheam> wget is fine for getting files
[2022-01-25T01:36:42Z] <acheam> but for anything more advanced
[2022-01-25T01:36:50Z] <acheam> curl is great
[2022-01-25T04:48:44Z] <testuser[m]> Hi
[2022-01-25T09:12:50Z] <Anonymouz> testuser[m]: Hi!
[2022-01-25T17:58:42Z] <Rohan> yo guys
[2022-01-25T17:59:01Z] <Rohan> anyone ever tested anbox in kiss?
[2022-01-25T18:18:08Z] <testuser[m]> https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt
[2022-01-25T18:44:28Z] <illiliti> someone needs to rewrite polkit in rust
[2022-01-25T18:44:52Z] <dilyn> polkit is unbased
[2022-01-25T18:45:56Z] <illiliti> looks like musl is unaffected(?)
[2022-01-25T18:45:58Z] <illiliti> > To convert messages from UTF-8 to another
[2022-01-25T18:45:59Z] <illiliti> charset, g_printerr() calls the glibc's function iconv_open().
[2022-01-25T18:46:31Z] <dilyn> lmfao
[2022-01-25T18:49:16Z] <testuser[m]> Bruh how could you get basic bounds checking wrong
[2022-01-25T18:54:50Z] <illiliti> > we note that OpenBSD is not exploitable, because its kernel refuses to execve() a program if argc is 0.
[2022-01-25T18:54:59Z] <illiliti> this is good hardening option tbh. linux should adopt this
[2022-01-25T19:06:36Z] <noocsharp> testuser[m]: everybody gets basic bounds checking wrong
[2022-01-25T19:06:48Z] <noocsharp> the more important question is how did it take them 13 years to realize
[2022-01-25T19:07:45Z] <dilyn> i like to think that a lot of these have been bugs which have been quietly exploited for years and years
[2022-01-25T19:08:35Z] <testuser[m]> noocsharp: u can avoid most of them by using asserts
[2022-01-25T19:09:08Z] <testuser[m]> I mean detect
[2022-01-25T19:09:53Z] <noocsharp> if only c did this by default...
[2022-01-25T19:10:30Z] <testuser[m]> But vro my nanoseconds
[2022-01-25T19:10:54Z] <noocsharp> and had an option to disable it if performance was critical
[2022-01-25T19:11:46Z] <testuser[m]> Nothing's stopping the brogrammer from putting them in though
[2022-01-25T19:12:13Z] <testuser[m]> I put asserts everywhere, most of the time i get an easy to fix assertion failure instead of segfaults
[2022-01-25T19:12:42Z] <noocsharp> but placing the burden on the programmer to do this is a point of failure if you're trying to write secure software
[2022-01-25T19:12:56Z] <illiliti> why assert if i have gdb
[2022-01-25T19:13:00Z] <noocsharp> ^
[2022-01-25T19:14:15Z] <noocsharp> why assert if i always write correct code the first time
[2022-01-25T19:14:49Z] <illiliti> i think assert can be useful for users, so they can easily report bugs, but for dev it's useless
[2022-01-25T19:15:00Z] <illiliti> imho
[2022-01-25T19:16:09Z] <omanom> that's essentially how assert statement is treated in python
[2022-01-25T19:22:11Z] <illiliti> i hate the fact that posix and iso c allows argv[0] to be NULL
[2022-01-25T19:22:43Z] <illiliti> it's just wrong and error-prone
[2022-01-25T19:23:59Z] <illiliti> at least openbsd did the right thing
[2022-01-25T19:24:48Z] <dilyn> as they always do
[2022-01-25T19:37:37Z] <noocsharp> go submit an rfc or whatever they call it for the next edition of posix
[2022-01-25T20:09:39Z] <illiliti> https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html
[2022-01-25T20:09:41Z] <illiliti> skip to rationale
[2022-01-25T20:09:57Z] <illiliti> > Early proposals required that the value of argc passed to main() be "one or greater"
[2022-01-25T20:10:10Z] <illiliti> > This requirement was removed from the ISO C standard and subsequently removed from this volume of POSIX.1-2017 as well
[2022-01-25T20:50:19Z] <maximum_yellow> what do people use for controlling volumes of pipewire?
[2022-01-25T20:51:00Z] <maximum_yellow> the only things i've found that do this are secretly pulseaudio clients, and require most of pulseaudio to be built and installed, even though they connect to pipewire-pulse
[2022-01-25T20:52:09Z] <tleydxdy[m]> shouldn't they only need the headers of some sort?
[2022-01-25T20:52:37Z] <maximum_yellow> tleydxdy[m] afaict they needed some .so's against which to link, but i could be doing this poorly
[2022-01-25T20:53:38Z] <tleydxdy[m]> if you have piperwire-pulse installed, it still won't build?
[2022-01-25T20:53:45Z] <tleydxdy[m]> I have not tried this very much tho
[2022-01-25T20:54:07Z] <maximum_yellow> tleydxdy[m] it would seem so, at least this particular one (and a few others iirc) want /lib/libpulse.so.0 
[2022-01-25T20:54:19Z] <maximum_yellow> which is not provided by pipewire-*
[2022-01-25T20:54:41Z] <dilyn> if you have pipewire set to manage your devices, you can use the usual tools you have always used to change volume
[2022-01-25T20:54:42Z] <maximum_yellow> or maybe it's libpulsecommon-15.0.so which is problematic
[2022-01-25T20:54:58Z] <maximum_yellow> dilyn but they seem to depend on pulseaudio being (mostly) present
[2022-01-25T20:55:01Z] <dilyn> for instance, I have pipewire setup with just alsa, and I use alsamixer
[2022-01-25T20:55:02Z] <maximum_yellow> at least to dompile
[2022-01-25T20:55:23Z] <tleydxdy[m]> very fun
[2022-01-25T20:55:35Z] <dilyn> pulseaudio is not required for pipewire to build
[2022-01-25T20:55:56Z] <maximum_yellow> dilyn true, but it is for the common volume management tools that use pulseaudio
[2022-01-25T20:56:09Z] <maximum_yellow> pamix, ncpamixer, pavucontrol, pactl, ...
[2022-01-25T20:56:12Z] <dilyn> sure, but you don't need those to manage your volume if you've always used alsa
[2022-01-25T20:56:31Z] <dilyn> you can use amixer and alsamixer as always
[2022-01-25T20:56:34Z] <maximum_yellow> does alsamixer allow for changing of individual application volume levels?
[2022-01-25T20:56:40Z] <maximum_yellow> if so then my problem is solved
[2022-01-25T20:56:58Z] <dilyn> I'm pretty sure that's what you would use pipewire to accomplish
[2022-01-25T20:57:08Z] <maximum_yellow> but through which interface
[2022-01-25T20:57:14Z] <dilyn> in either case the answer is probably "yes, if you do some documentation"
[2022-01-25T20:57:21Z] <dilyn> well I don't know; whatever interface is set up to do such a thing
[2022-01-25T20:57:42Z] <dilyn> s/some documentation/some documentation reading/
[2022-01-25T20:57:57Z] * maximum_yellow is doubtful that alsamixer understands per-connection levels for pipewire clients
[2022-01-25T20:58:00Z] <maximum_yellow> but i'll give it a go
[2022-01-25T20:59:47Z] <tleydxdy[m]> fedora seems to have pipewire-libpulse
[2022-01-25T20:59:51Z] <tleydxdy[m]> not sure how they do that
[2022-01-25T21:00:26Z] <maximum_yellow> oh cool, thanks for the tip!
[2022-01-25T21:30:00Z] <omanom> based on this: https://docs.pipewire.org/page_daemon.html that makes me think per-application volume control would be something within Pipewire's configuration, and alsamixer/amixer would just be like a "master" volume control