<midfavila>
testuser[m]: shell is good for prototyping or commands that won't be used often, or that would be too cumbersome to write in C
<midfavila>
also, update on fetch, feature parity with hurl has just about been reached
<midfavila>
supports HTTP, TLS and Gopher atm
<midfavila>
in 1/4 the lines of C and 1/2 the binary size :D
<midfavila>
a lot of the former is redundant though, I need to write a couple of abstraction functions
<midfavila>
HTTP response header stripping over TLS is also kind of buggy
<midfavila>
but otherwise I've been using it as my primary file transfer utility over the past few days and there don't seem to be many implementation errors aside from what was already mentioned
<phoebos>
:D do push it to your git server
<midfavila>
will uwu
<midfavila>
main is still kinda crappy, but it's also still beta-quality, so, meh
<midfavila>
i'll take it into consideration, but i don't think a sane individual would ever close 0, 1 and 2 before executing apport. if they do, there are bigger concerns than a failed socket()
<illiliti>
this 'if' implies that it isn't
<illiliti>
this is wrong and bad
<midfavila>
wrong, in theory. in practice, the worst thing that would happen is apport aborts.
<phoebos>
either way, you're currently testing for 0 or nonzero, which isn't the difference between success and failure of socket
<illiliti>
yeah
<midfavila>
yeah, and that's fair.
<illiliti>
you just need to stop assuming that everything returns a bool
<phoebos>
ideally you'd also not assume AF_INET
<midfavila>
UNSPEC or whatever, right?
<phoebos>
UNSPEC for getaddrinfo, then getaddrinfo tells you what to use
<midfavila>
aah, fair enough
<phoebos>
like you do in connect; socket should also come after getaddrinfo
<illiliti>
i think i see a potential fd leak
<illiliti>
you too?
<illiliti>
due to early returns
<illiliti>
sd will be leaked
<midfavila>
i should probably rewrite dial at some point soon. was one of the earlier functions, wrote it when i was pretty braindead
nullcoder has joined #kisslinux
<midfavila>
fd leak... should definitely be addressed, but it's also not a problem in practice
<midfavila>
at least in this specific case
<phoebos>
you can also freeaddrinfo
<illiliti>
gopher.c:13
<illiliti>
i think you need another byte for NUL
<midfavila>
yeah, there are a few calls to malloc, getaddrinfo and etc that could and probably should have cleanup in main, before a stable release
<illiliti>
cuz REQ_GOPH contains newline
<illiliti>
oh wait no
<illiliti>
no it should be fine
<midfavila>
yeah i was gonna say
<illiliti>
but you would add assert just in case
<illiliti>
I*
<illiliti>
assert for sprintf return value
<illiliti>
ret == buflen
<illiliti>
to confirm that your calculation is correct
<midfavila>
ret+1, but fair enough
<phoebos>
why do you close(sd) when doing tls?
<midfavila>
so I can use tls_connect
<midfavila>
plan is/was to upgrade the socket
<midfavila>
but I wanted TLS working as soon as possible and tls_connect is easier to use
<phoebos>
ah
<midfavila>
otherwise a spare socket is floating around for the lifetime of the program
<illiliti>
main.c:179
<midfavila>
also re: assert I'm fairly certain that the program would abort long before dial() if an error occurs that would render the total string length calculation erroneous
<midfavila>
(strlen(N_REQ) + strlen(path) + 1) only assumes that path is a string -- but considering dial() is called after uri_parse, which validates and breaks apart input, it's never passed anything that isn't a string
<illiliti>
i would use memmem here
<illiliti>
memmem will be posix
<midfavila>
if it's not in posix, i won't use it
<illiliti>
it's in draft
<midfavila>
it could be in draft for years
<illiliti>
ok
<midfavila>
if i define my own version and then say i'll clean up later, versus using functions that are already in posix, there's no chance of spontaneous breakage
<midfavila>
i've encountered a huge number of programs that do this
<illiliti>
make sure that recvbuf is nul-terminated then
<midfavila>
recvbuf is because it's bufsiz+1 and the for loop continously memsets it to null, but recv/tls_read calls only accept BUFSIZ bytes
<illiliti>
ok
<illiliti>
assert wouldn't hurt here too
<kqz>
<testuser[m]> "it doesnt detect my mic unless i..." <- i have the same issue with pipewire and mdevd/libudev-zero, haven’t been able to find a solution
<illiliti>
same question: did it work for you before?
<kqz>
nope, works when I switch to eudev though so not sure if mdevd config issue or libudev zero incompatibility with pipewire
<illiliti>
pipewire is from community, right?
<wael[m]>
es
<kqz>
yeah
<kqz>
seems racy too, every now and again it’ll detect it without me having to restart pipewire
<illiliti>
hmm
<illiliti>
someone need to debug this
<illiliti>
i doubt it will be me cuz i don't use pipewire
<illiliti>
i would recommend starting with bisecting spa/plugins/alsa/alsa-udev.c
<kqz>
i can investigate some more and see, not sure if any specific release or commit broke it though I’ve noticed the issue for a while
wael_ has quit [Quit: Bridge terminating on SIGTERM]
konimex has quit [Quit: Bridge terminating on SIGTERM]
testuser[m] has quit [Quit: Bridge terminating on SIGTERM]
virutalmachineus has quit [Quit: Bridge terminating on SIGTERM]
wael[m] has quit [Quit: Bridge terminating on SIGTERM]
psydroid has quit [Quit: Bridge terminating on SIGTERM]
kqz has quit [Quit: Bridge terminating on SIGTERM]
macslash1[m] has quit [Quit: Bridge terminating on SIGTERM]
saturn[m] has quit [Quit: Bridge terminating on SIGTERM]
saturn[m] has joined #kisslinux
testuser[m] has joined #kisslinux
psydroid has joined #kisslinux
virutalmachineus has joined #kisslinux
konimex has joined #kisslinux
wael[m] has joined #kisslinux
wael_ has joined #kisslinux
macslash1[m] has joined #kisslinux
kqz has joined #kisslinux
<wael[m]>
why did dylan make the decision to switch to wayland?
<midfavila>
probably because from an engineering standpoint wayland is significantly simpler than X11
<wael[m]>
yeah idk why i need dbus or pipewire or tons of dependencies for screensharing
<wael[m]>
maybe the engineering standpoint sure but theres no control in the wayland standards and i just find what weird
* midfavila
shrugs
<midfavila>
i'm still using x11 and i'll continue to until mgr or some similar display system is brought up
<midfavila>
what wayland does is of no consequence to me
<wael[m]>
maybe it needs bloated garbage like dbus and pipewire for ''''''''''''''security'''''''''''''''' but idk
<wael[m]>
i wish there was a XCB/Xlib to wayland, one library that just does wayland stuff. but unfortunately wayland is more of a specification protocol
<testuser[m]>
wael: actually none of that shit is technically needed for screen sharing
<testuser[m]>
Like wf-recorder works just fine
<noocsharp>
nothing about wayland forces dbus or pipewire, it's just that that's become the standard for screensharing
<testuser[m]>
But it's used as an abstraction over various compositors
<testuser[m]>
U can fork webrtc to add non pipewire back end
<wael[m]>
but why did it have to be like this tho
<testuser[m]>
Because everyone uses dbus
<noocsharp>
go write the patches to fix it wael[m]
<wael[m]>
maybe if i knew C or Rust i would
<testuser[m]>
Ye
<testuser[m]>
Then learn
<testuser[m]>
No point in shitting on things you can't provide an alternative for
<midfavila>
that's fallacious,
<midfavila>
but the underlying message is sound
<midfavila>
something something be the change you want to see in the world
<wael[m]>
testuser[m]: xorg
<wael[m]>
idk wayland is like the new thing and many things are switching to it
<midfavila>
then just don't use those things
<testuser[m]>
midfavila: i mean shitting on stuff without suggesting ways to improve / suggesting an alternative that already exists
<testuser[m]>
Like u can say this dish sucks
<testuser[m]>
But why does it
<testuser[m]>
and how to fix
<midfavila>
plenty of software and documentation exists for X wael[m]
<wael[m]>
eh ur right
<wael[m]>
but is there any advantage to wayland other than security?
<testuser[m]>
And package/dependency count is meaningless
<testuser[m]>
You could have a program that's super fat with no external deps
<wael[m]>
i got out of that mindset
<wael[m]>
what it depends on kinda matters more
<testuser[m]>
And a smaller one which has many deps but combined they're still lless complex than that one package
<midfavila>
it's not entirely meaningless, but it's only part of a larger equation
<wael[m]>
testuser[m]: aka flatpak lol
<testuser[m]>
if you were to unbundle every single bundled library from chromium it would add to like 30 packages
<testuser[m]>
Or something
<noocsharp>
the core wayland protocol is smaller than X, the downside is that it doesn't include everything everyone would want out of a window compositing protocol
<noocsharp>
the upside is your can choose what you care about
<wael[m]>
so from an engineering standpoint wayland is much easier to implement yes?
<wael[m]>
which is why i assume dylan chose it
<midfavila>
isn't wayland also largely linux specific?
<wael[m]>
no
<midfavila>
i know fBSD has their own compositor that they're working on, but I've not seen it be adopted much outside Linux
<wael[m]>
but still, again, but is there any advantage to wayland other than security?
<midfavila>
uh, it's conceptually simpler and it's free of cruft
<wael[m]>
aaand?
<midfavila>
that's really all it needs
<noocsharp>
it's easier to debug and fix
<midfavila>
if all you want is to dump windows on a framebuffer wayland will get you there faster than X
<midfavila>
of course, X has peripheral support, flexibility and legacy compat on its side
<noocsharp>
wdym peripheral support?
<midfavila>
X still has the ability to handle things like monochrome displays and other less common interface devices
<midfavila>
of course, that's not suuuuper relevant in today's world
<midfavila>
but being able to choose four-bit color instead of 32-bit on my e-reader and the inverse on my desktop is a very nice feature to have
<midfavila>
i'm sure a wayland compositor could do the same, but... well, it would only be one wayland compositor
<wael[m]>
hm
<noocsharp>
32-bit color would still work on eink, right? just a waste of computation?
<midfavila>
yes
<noocsharp>
waste of computation when rendering at 32-bit instead of 4 that is
<midfavila>
and a massive waste of memory
<wael[m]>
because its 38 years old.
<noocsharp>
ah
<midfavila>
and considering it's a mobile device, memory usage and energy usage are fairly important
<midfavila>
also jfc why is android so shit
<midfavila>
there are no half-decent standalone ftp clients
<testuser[m]>
ftp deprecated broo
<noocsharp>
sftp
<testuser[m]>
midfavila: use termux
<midfavila>
sftp is gay and i'm already using termux
<midfavila>
it's just a pain in the ass having to tap out individual letters using my styli
<wael[m]>
youre gay
<midfavila>
uwu~
<wael[m]>
what the fu
Glitch[m] has joined #kisslinux
<Glitch[m]>
wael: helow awael
<wael[m]>
hello glitch
<Glitch[m]>
im use burger linu x\
<testuser[m]>
Wat
<Glitch[m]>
best dsitro
<Glitch[m]>
bruegrign l;uinuxes
Glitch[m] has left #kisslinux [#kisslinux]
<wael[m]>
never come back
<testuser[m]>
Tf is buger linux
<wael[m]>
he is doing a little bit of trolling
<midfavila>
yeah i have no clue how people can tolerate using android...
<midfavila>
even just transferring a file is painful
<midfavila>
i guess if you used webshit it would be tolerable
<testuser[m]>
That's literally what it's meant for
<midfavila>
hell
<midfavila>
can't wait until pmos can be flashed to the pine note
<illiliti>
> isn't wayland also largely linux specific?
<illiliti>
yes, absolutely
<illiliti>
don't even mention freebsd support
<illiliti>
it is joke
<wael[m]>
aw
<illiliti>
everytime people say that wayland supports freebsd, i cringe
<illiliti>
i mean look at what freebsd did to get this "support"
<illiliti>
instead of forcing wayland to use freebsd native interfaces, they forced freebsd to implement linuxism
<illiliti>
libudev, evdev, libinput, epoll and other crap
<illiliti>
i would not call this support
<illiliti>
it's rather shim programming that a proper support
<illiliti>
proper support is when software relies on OS's native interfaces
<illiliti>
what wayland did is ridiculous
<phoebos>
lol xcb and Xlib are different libraries using the same protocol
<phoebos>
hi noocsharp
<midfavila>
fwiw xlib just sits on top of xcb these days
<noocsharp>
hi phoebos
<noocsharp>
illiliti: and when a system implements an interface it becomes native
<testuser[m]>
phoebos: but there could be an xz that doesn't even use -d/-c for (de)compression
<testuser[m]>
The file format is well specified
<testuser[m]>
But not any utility
<testuser[m]>
Should be trivial to stub -T for any dev
<testuser[m]>
For compression xz definitely benefits a lot from threads
<illiliti>
of course, if said system is a linux puppet it will implement all shims and all interfaces
<illiliti>
no matter how bad they are and no matter that system already have similar interface
<illiliti>
only matter is result, right?
<phoebos>
testuser[m]: if we find an xz that doesn't implement -d then we'll work around it
<phoebos>
but there is one that doesn't support -T
<phoebos>
however, i'll send them a message to see if they'll stub it
nullcoder has quit [Ping timeout: 256 seconds]
Torr has joined #kisslinux
nullcoder has joined #kisslinux
nullcoder has quit [Ping timeout: 252 seconds]
nullcoder has joined #kisslinux
nullcoder has quit [Ping timeout: 268 seconds]
nullcoder has joined #kisslinux
nullcoder has quit [Ping timeout: 268 seconds]
nullcoder has joined #kisslinux
da5id has joined #kisslinux
<da5id>
trying to install kiss for the first time and noticed that the official repo is outdated. Im on the step for listing all of the /var/db/kiss/installed and building them all but zlib gets a 404 for version 1.2.11 is there a newer repo to point to that im not aware of?