soliwilos has quit [Remote host closed the connection]
soliwilos has joined #kisslinux
fitrh has joined #kisslinux
<midfavila>
woot, ssh client and server are up in the chroot
an3223 has quit [Remote host closed the connection]
an3223 has joined #kisslinux
an3223 has quit [Remote host closed the connection]
an3223 has joined #kisslinux
ejjdhfjsu_ has joined #kisslinux
ejjdhfjsu has quit [Ping timeout: 268 seconds]
<virutalmachineus>
what happen to dylan?
fitrh_ has joined #kisslinux
fitrh has quit [Ping timeout: 260 seconds]
GalaxyNova has joined #kisslinux
fitrh_ has quit [Read error: Connection reset by peer]
fitrh has joined #kisslinux
soliwilos has quit [Write error: Connection reset by peer]
an3223 has quit [Remote host closed the connection]
soliwilos has joined #kisslinux
an3223 has joined #kisslinux
GalaxyNova has quit [Ping timeout: 244 seconds]
<wael[m]>
Dylan is uhhh
<wael[m]>
honestly idk just pretend he is retired and taking a break
<testuser[m]12>
~~He's working on proprietary software in private shithub repos~~
<testuser[m]12>
Hi
<wael[m]>
Hi testuser or git-bruh or Gupta or idfk what I'm supposed to call yoy
<testuser[m]12>
Lol I'm not gupta
<testuser[m]12>
That's a local meme
<testuser[m]12>
There's this scummy edtech company who used a fictional 13 yr old kid "wolf gupta" in their marketing saying that he got 150k usd job (in India) at google at 13 yrs lol
<testuser[m]12>
12-year Old Wolf Gupta learnt AI to get Rs 1.2 cr job from Google while other kids his age didn’t know what to do after school. Coding makes your kids entrepreneurs and scientists in the new world. World’s first 1:1 AI coding course for kids. Free Trial. Age 6-18 Only
<wael[m]>
What do I call youuu
<testuser[m]12>
testuser
<wael[m]>
more like
<wael[m]>
customer
soliwilos has quit [Remote host closed the connection]
soliwilos has joined #kisslinux
iceman[m] has joined #kisslinux
<iceman[m]>
Hello Good day everyone!
<testuser[m]12>
hi
<iceman[m]>
am I in
<testuser[m]12>
yeah
iceman[m] is now known as iceman
iceman is now known as iceman[m]
<iceman[m]>
Nice
<wael[m]>
iceman more like
<wael[m]>
boilingman
<iceman[m]>
them I am steamman
<iceman[m]>
☁
ejjdhfjsu_ has quit [Remote host closed the connection]
child has joined #kisslinux
rohan has quit [Ping timeout: 268 seconds]
<testuser[m]12>
noocsharp: firefox doesnt even need perl for anything
midfavila has quit [Read error: Connection reset by peer]
fitrh has quit [Quit: fitrh]
<sad_plan>
testuser[m]12: im on it
<sad_plan>
why on earth does always fossies.org just delete their old tarballs? its really annoying
<wael[m]>
to save space i guess
<sad_plan>
well that could be one reason for it..
ioraff has joined #kisslinux
soliwilos has quit [Ping timeout: 258 seconds]
soliwilos has joined #kisslinux
soliwilos has quit [Remote host closed the connection]
soliwilos has joined #kisslinux
ioraff has quit [Remote host closed the connection]
ioraff has joined #kisslinux
soliwilos has quit [Remote host closed the connection]
soliwilos has joined #kisslinux
<ioraff>
testuser[m]12: how about libressl?
<sad_plan>
ioraff: add that as a proposal?
<testuser[m]12>
Yeah make an issue, I don't think it's viable cuz of compatibility issues
<sad_plan>
is there anything in particular that isnt compatible that you can think of? rust is one thing that comes to mind anyway. python will need a patch, but Ive one on hand in any case. there are several of us that use libressl, so I dont really think it too much of an issue imo
<testuser[m]12>
Python and rust only, but the patches will grow bigger and bigger as new apis start being used
<illiliti>
rust considers switching to rustls iirc
<illiliti>
it's total garbage but at least it works and i can understand it unlike perl
<illiliti>
i'll consider rewriting it in python and sending it to upstream, maybe
<testuser[m]12>
illiliti: nice
<sad_plan>
testuser[m]12: yeah, I know.. thats one of the perils of using niche software. in any case, bsds use libressl, so Im sure we can use patches from those guys, or atleast work off of them
sad_plan has quit [Quit: nyaa~]
phoebos[m] has joined #kisslinux
ioraff has quit [Ping timeout: 255 seconds]
ioraff has joined #kisslinux
riteo has joined #kisslinux
<riteo>
hiiiiiiiiii!
<riteo>
I just read the log part about the mdev wrapper and how scripts are bad because of forks
<riteo>
wasn't the issue with hotplug just the fact that at boot it would call scripts for all of the devices and absolutely blast very weak computers?
<riteo>
all at once
<ioraff>
yes
<riteo>
well, I guess that one could make some sort of """""universal""""" rule language and then make it a "script" called by mdev
<riteo>
it'd still fork, but way less
<riteo>
I mean, in compiled C
<riteo>
yeah I meant a rule parser in C for something made to be device manager agnostic which would then be called by mdev
<ioraff>
the hotplugger itself being called a bunch of times is also an issue
<riteo>
I wonder, couldn't it just be called serially?
<riteo>
instead of all at nce
<riteo>
s/nce/once
<ioraff>
perhaps. it may also be less of an issue with a busybox/toybox/whatever device manager, since elf overhead won't be a factor
<illiliti>
that would be slow anyway
<riteo>
yeah but how much
<illiliti>
imagine forking script for each uevent
<riteo>
I see your point
<riteo>
perhaps one could make a listener? But that might as well be a device manager, wouldn't it?
<riteo>
my approach used an mdev rule for the USB subsystem, so it definitely isn't for each uevent
<riteo>
but it's surely more limited than the amalgamated mdev rules
<riteo>
what if we really made a listening daemon though
<illiliti>
what it would do
<riteo>
it'd read some "generic" device managment language and... manage devices
<riteo>
which is well, a device manager
<riteo>
oof
<riteo>
yeah that won't do
<riteo>
the thing is, can we really avoid the forking while staying dm agnostic?
<riteo>
I'm not really that's even a problem if it's enabled post boot, it's not like hotplugs are *that* frequent
<riteo>
s/I'm not really/I'm not really sure/
<riteo>
and speed isn't the #1 priority, it's not like the priority is the absoulely fastest device configuration routine ever, expecially since as I said hotplugs are actually pretty rare
<illiliti>
i think we still could experiment with scripts
<illiliti>
we could just make them optional maybe
<riteo>
technically, they would already be, in my case it's just an mdev rule
<riteo>
you can pop that off the config and the "framework" would effectively be disabled
<riteo>
I haven't checked, but I'm pretty sure all dm supports running hotplug scripts
<illiliti>
i.e basic functionality is handled by device manager. additional functionality such as package-specific rules could be installed as scripts
<illiliti>
by basic i mean setting up permissions for /dev/null, /dev/input and stuff
<riteo>
perhaps we could do a bit of a compromise
<riteo>
what if we made some small sub-scripts/c programs that handled their own extremely specific configuration?
<illiliti>
how they would do that
<illiliti>
via device manager or on their own?
<riteo>
via device manager
<illiliti>
ok
<riteo>
I've published my small POC which actually does something like that in a ticket thread
<riteo>
running small c programs would limit forks by a lot, wouldn't it?
<riteo>
the `/etc/mdev.d/usb/usbgroup.sh` file could be turned into a (better) C program and the dispatcher script could be removed perhaps, or there could be a dedicated rule, dunno
<illiliti>
forking isn't an issue if you don't do it for every uevent
<riteo>
wait, are uevent device-related only or do they do a lot more?
<illiliti>
mostly device-related
<riteo>
then I guess that if we want to allow a lot of control that it has to be on every/almost all uevents
<riteo>
like the device add and device remove ones
<riteo>
if they even exists in such form, don't really remember, sorry
<riteo>
perhaps you meant that the issue would be for every netlink message?
<illiliti>
it's same thing, more or less
<illiliti>
because uevent based on netlink
<riteo>
yeah, but unless uevent handles a *lot* of things (list of which I'm still searching online) I guess that it'd be pretty much irrelevant to do it on every uevent
<riteo>
worst case we could just handle device additions and removals, no?
<riteo>
which is what /sbin/hotplug does actually
<riteo>
reading online it just handles additions and removals, so I don't see the problem tbh
<illiliti>
there are also device change events
<illiliti>
online offline events
<riteo>
mh, but we don't care about such events, do we?
<illiliti>
i think we should care about change event
<riteo>
then we could perhaps invoke the script only if these events happen?
<riteo>
if there are a lot of uevents we don't need
<illiliti>
yeah, but isn't the initial idea to give user full control over it?
<illiliti>
instead of selecting events which should be handled
<riteo>
then I don't think we really have many options around this if we want to stay dm agnostic
<riteo>
no wait I think there might be a lot of uevents
<illiliti>
we could delegate basic functionality to device manager
<riteo>
yeah that for sure
<riteo>
the focus is allowing packages to have special features embedded
<riteo>
with the dm
<illiliti>
we could just let packages to install scripts for device manager.
<illiliti>
user will have to specify them in device manager
<riteo>
I would like to avoid this approach, as it's pretty easy to mess up and too manua
<riteo>
s/manua/manual/
<illiliti>
so you want udev approach
<riteo>
that's definitely what we're trying to avoid
<riteo>
the argument for some sort of framework is to avoid depending on a specific devman
<riteo>
udev has made some hellish abomination which wants exactly the opposite
<illiliti>
it's not possible because we can't decouple basic functionality into scripts
<riteo>
basic functionality would stay in the devman configuration
<illiliti>
ok
<riteo>
I'm talking about the extra stuff packages might want to add
<riteo>
I'm starting to wonder though why /sbin/hotplug might give issues
<riteo>
it's only called on additions and removals, which is enough for 99% of uses
<riteo>
hell, said 99% are just the usb thing which could be done in a simpler configuration language
<riteo>
if you see my poc it's pretty much a grep and a read
<riteo>
and one might as well port it in C
<riteo>
IIRC *all* of our troublesome packages have the same usecase for eudev
<illiliti>
i see
<illiliti>
having scripts is fine as long as we don't touch basic functionality
<riteo>
that was never the scope of the proposal actually
<illiliti>
we just need to make device manager aware of that scripts
<riteo>
That's simple if running it on every devman event is acceptable
<riteo>
that'd be the easy route
<illiliti>
hm
<riteo>
otherwise we could make some still "configurable" but specific script that does eg. the usb thing
<riteo>
but manual intervention is kinda bad IMO
<riteo>
and still, it'd become part of the "base" framework in case we avoided it
<riteo>
just to wrap my point (I have difficulty at ending discussions) I might settle on the idea of domain specific configuration languages dispatched by a main script
<riteo>
a decent compromise IMO
<illiliti>
could we filter scripts based on subsystem? i.e if subsystem == usb, then run scripts in /etc/hotplug.d/usb/*
<illiliti>
instead of having main script
<illiliti>
catch-all script*
<riteo>
what difference would that make?
<riteo>
if we made a script for each subsystem, it'd still call a script everytime
<riteo>
we could perhaps avoid some forks though
<illiliti>
yeah, but if user doesn't have scripts for usb subsystem, we could avoid needless fork
<riteo>
that'd make sense
<riteo>
y'know what
<riteo>
in the worst case if subsystems aren't defined we could do the (kinda scary) approach of making the subsystem name lowercase and using it as a directory for checking the scripts
<riteo>
I mean, it's the kernel giving us the subsystems string, so it shouldn't be a problem
<illiliti>
yeah
<riteo>
then I think we got an even better compromise
<riteo>
with this we should be covered for 99% of usecases, with the remaining 1% left for either problem specific solutions or something else on which we don't care rn
<illiliti>
we could make it event-specific as well
<riteo>
I think that'd be excessive
<riteo>
but I could start experimenting and tell you
<riteo>
I still think that going per subsystem we should be all right
<riteo>
tbf we could even be ok with just the usb thing handler, but that sounds very, very risky
<illiliti>
and too specific
<riteo>
yup
<riteo>
we might need further managers and stuff would pile up too much
<riteo>
no wait there's an issue
<riteo>
how do we actually do the directory handling
<riteo>
we would still need a main dispatcher script, wouldn't we?
<riteo>
it'd parse the subsystem string and then look for scripts
<riteo>
I mean it shouldn't make much of a difference, right?
<illiliti>
you could inline for loop in mdev.conf
<riteo>
ehhhh I don't think that would be much different than a generic script
<riteo>
also I fear that it'd might narrow down the compatible dm list
<illiliti>
SUBSYSTEM=usb;.* root:root 660 @for f in /etc/hotplug.d/usb/*; do ...
<riteo>
shouldn't the inlined for loop still fork /bin/sh?
<riteo>
oh no wait, I don't think we know all the possible subsystems
<riteo>
I thought about making a script that takes the subsystem env and uses it as a directory for scripts
<riteo>
it'd still be 1 fork per subsystem
<riteo>
at least
<illiliti>
but that's a catch-all script
<riteo>
yeah but if we put a script for each subsystem it would make little to no difference
<riteo>
it'd still be one script called each time
<riteo>
the savings come from the differention per directory
<riteo>
so that we avoid forking usb scripts that quit right away because we're in the dri subsystem
<riteo>
dunno if you get my point
<riteo>
or if it makes sense
<illiliti>
how you would implement that differention
<riteo>
with a catch all script that looks for a specific directory depending on the subsystem
<riteo>
it'd still be one fork
<riteo>
the logic is that if we put a script for each subsystem that it'd be still one fork at every event
<illiliti>
SUBSYSTEM=.*;.* root:root 660 @for f in /etc/hotplug.d/%1/*; do ...
<illiliti>
idk if it works
<riteo>
wait what would %1 do
<riteo>
but still, I'm pretty sure that the @ argument would equal one sh fork
<illiliti>
according to mdev conf spec, %1 will be replaced by the match from regex
<riteo>
and since it isn't garaunteed to be implemented in this way for every dm I'd just make a small script with that for loop and ask users to configure their specific dm to just run it
<riteo>
I think that the %1 would be replaced by the device directory
<riteo>
or whatever that `;.*` refers to
<illiliti>
ignore `;.*`
<illiliti>
it basically says mdev that we don't care about other uevent variables
<riteo>
are you sure that mdev even handles non dev-subsystem related events?
<riteo>
I don't have hotpluggable devices rn but it looks to me that everything it does has always a subsystem
<riteo>
like if I mess up with my backlight it has the subsystem backlight
<riteo>
to test what mdev sees you can run `mdev -vfd`
<illiliti>
i use mdevd
<riteo>
does mdevd have a verbose flag?
<riteo>
-v here is verbose, -f is foreground and -d is "daemon, listen on netlink"
<illiliti>
it does, but i don't know if it's useful
<riteo>
I think that it's supposed to only have subsystem stuff
<riteo>
reading from busybox's big comment on top of their mdev source it says that it by default is a hotplug helper that reads `$SUBSYSTEM` and `$DEVPATH`
<riteo>
so I imagine that it being in daemon mode would just imply it doing the same thing but without the kernel hotplug facility
<illiliti>
so we can freely rely on subsystem
<riteo>
I think so? To be sure we could log unexpected results like an undefined/empty subsystem into some file
<riteo>
it says that it handles hotplug events from the netlink. Since hotplug events must have the subsystem variable set we can rely on it 100% of the time