farkuhar has quit [Quit: nyaa~]
<ukky> btw at work I made mdev plus libudev-zero setup on Gentoo and it works well. xorg-xf86-input-evdev works via libudev-zero. Even lsusb works, though complains missing function in libudev.so, like version.
Olutmies has joined #opencrux
<Olutmies> Well I don't have and *dev. No need when the e
<Olutmies> When the kernel does what I need
<Olutmies> And/any*
Olutmies has quit [Ping timeout: 250 seconds]
Quintero-Habana- has joined #opencrux
<Quintero-Habana-> Okay, back in office
<Quintero-Habana-> Looks like stuck in KL for another day
<Quintero-Habana-> Waiting for parts from Japan for Toyota
Quintero-Habana- has quit [Ping timeout: 250 seconds]
zorz has joined #opencrux
Quintero-Habana- has joined #opencrux
Quintero-Habana- has quit [Ping timeout: 250 seconds]
farkuhar has joined #opencrux
<ukky> devtmpfs works too if run a manual script after each dynamic arrival/removal of a device, to change ownership and permissions. For Xorg, you can resurrect xorg-xf86-input-keyboard and xorg-xf86-input-mouse, which do not require libudev.so
<farkuhar> ukky: Would the script need to be invoked manually, or can it be triggered to run automatically whenever the kernel detects a hardware change? The latter method is how it works with /etc/udev/rules.d/
<ukky> farkuhar: kernel calls udev directly for all device events and that's why it must be resident.
<ukky> mdev gets kernel notifications via /proc/sys/kernel/hotplug
<ukky> You can also install your private script to handle kernel events.
<ukky> Intercepting /proc/sys/kernel/hotplug is the way to learn what messages kernel sends when new device arrives.
<ukky> farkuhar: Any distro which maintains device rules at /etc/udev/rules.d/ needs SystemD code (eudev, systemd-udev, or full systemd ecosystem).
<farkuhar> ukky: My current CRUX laptop doesn't have /proc/sys/kernel/hotplug, but when I run `zgrep -i hotplug /proc/config.gz` it appears that all those drivers were built, either as modules in directly in the kernel. Is there another name for the driver that provides /proc/sys/kernel/hotplug?
<ukky> farkuhar: Kernel exposes /proc/sys/kernel/hotplug when CONFIG_UEVENT_HELPER is enabled
<ukky> Device manager sets /proc/sys/kernel/hotplug to a path to binary/script which will handle kernel device events. For me, it's set to /sbin/mdev
<ukky> s/Device manager sets/OS startup script sets/
<ukky> Sometimes I do this: echo '/usr/local/bin/mdevexectrace' > /proc/sys/kernel/hotplug
<farkuhar> ukky: Thanks, that's the option I was looking for. It looks like my currently-loaded kernel was built with CONFIG_UEVENT_HELPER not set.
<ukky> mdevexectrace is a shell script, which can log parameters and environment passed by the kernel
<ukky> CONFIG_UEVENT_HELPER is not required for SystemD setup (udev, eudev)
<ukky> Be carefull of multiple events executing the same shell script. When you log messages, use SEQNUM environment variable, set by kernel, to differentiate events.
<ukky> s/carefull/careful
<ukky> farkuhar: you can try my script to inspect events: https://0x0.st/KrT4.sh
<farkuhar> From the beginning, CRUX users were responsible for configuring and building their own kernels, even though it was expected that they would mostly follow the official repositories for the ports. Why wasn't the user autonomy in kernel configuration also extended to the choice of uevent handlers (mdev versus eudev)?
<farkuhar> I can imagine a future CRUX handbook that not only documents the various choices for boot manager (LILO and friends), but also offers some guidance for choosing and configuring a uevent handler.
<ukky> There are many reasons for that. For one, there are no current maintainer who is intereseted in supporting multiple init systems, nor device managers.
<farkuhar> Core maintainer, you mean. It was only a few hours ago that #crux saw a new user volunteer to help edit the wiki.
<farkuhar> tsundokuboi is the one who volunteered to clean up the wiki typos.
<remiliascarlet> A niggerpill just for you.
<ukky> Yes, core maintainers are not interested in supporting any combo except sysvinit+eudev
<remiliascarlet> Init systems are another pain to deal with, especially with server-side software. Each BSD has its own, and it's only 1 init system. Linux has a dozen of them, one of which is essentially an OS.
<farkuhar> remiliascarlet: Why does zorz need to be blackpilled regarding Wayland? As far as I recall, none of his recent projects or installations have been centered around Wayland.
<remiliascarlet> farkuhar: Because he seems to love it.
<remiliascarlet> But then again, zorz is the type of guy who loves whichever piece of software he just finds out about.
<remiliascarlet> If he were to just hear about the existence of Windows today, he would probably enthusiastically recommend it for at least a few weeks.
<ukky> haha
<farkuhar> I find it hard to believe that zorz just found out about pkgsrc. But that was the software he was constantly mentioning in recent days.
<remiliascarlet> Don't tell him about the Nix package manager then.
<remiliascarlet> Also don't tell him about 6502 Assembly on one of these SBC's: https://www.imania.dk/product_info.php?currency=EUR&cPath=204&products_id=7231&language=en
<farkuhar> I would like to see what happens if we sign him up for a Plan9 boot camp, though.
<farkuhar> ukky: Okay, the core maintainers can limit their support to a single init system, while still allowing users full autonomy over the kernel configuration. Is there a way to extend the user autonomy to the choice of device manager too? Replace the hard-coded /sbin/start_udev line in /etc/rc with a more flexible path like /etc/alternatives/device_manager, which would be a symlink to whatever shell script
<farkuhar> the user prefers.
<remiliascarlet> Tech journalism: "Somebody released a new version of some software? Quick, write about how evil Trump is and how we should care about the climate hoax!"
<remiliascarlet> YouTube journalism: "A company wrote a 10 word long Tweet? Quick, make a 25 minute long video covering that one Tweet!"
<ukky> farkuhar: If we drop multi-init system support from discussion, /etc/rc still has to be re-written to accomodate for major device manager alternatives.
<farkuhar> ukky: It would have been more forward-thinking of them to move all the eudev-specific logic into the /sbin/start_udev script, and that way it would only require changing that one line of /etc/rc. Is it one of the /bin/mount commands that needs to be changed, to support an alternative device manager?
<ukky> This section assumes system will either have SystemD's udev or no device manager: https://git.crux.nu/tools/rc/src/branch/master/rc#L71
<ukky> Though, if initramfs has mounted /dev as tmpfs, it will be kept as tmpfs.
<farkuhar> Why didn't they just let lines 71-90 be absorbed into the /sbin/start_udev script, then? Users who want to set up a different device manager can mount and populate the subdirectories of /dev with a different script.
<ukky> Core maintainers do not expect/assume there might be alternative device manager.
<ukky> I tried to accomodate both udev and mdev in my runit startup script, but I never tested it with udev
<farkuhar> I'm talking about the "separation of concerns" principle, though. Why clutter /etc/rc with commands that assume a particular device manager, when it's perfectly equivalent to put all those commands into the script that ships with core/eudev?
<ukky> Agree. Current lines 71-93 could be merged with content of /sbin/start_udev. /sbin/initdevman should replace lines 71-93. /sbin/initdevman should be a symlink to /sbin/start_udev when udev is selected a device manager.
_whitelogger has joined #opencrux
<zorz> remiliascarlet: 15th Augost, Orthodox.....ii
ukky has quit [Ping timeout: 252 seconds]
ukky has joined #opencrux
SiFuh_ has quit [Remote host closed the connection]
SiFuh_ has joined #opencrux
<zorz> 15th Augost, Orthdox.
<zorz> farkuhar: forget it for now.
<farkuhar> zorz: Do you use LVM2 on any of your machines?
<farkuhar> According to my notes, CRUX-MUSL 3.7 did not go so far as to remove eudev from core (although they did remove sudo, linux-pam, and dumb_runtime_dir), because it would have required major patching of lvm2 and sysvinit.
<farkuhar> I wonder if my notes erroneously mentioned core/sysvinit when it should have been core/rc (as discussed above). We seem to have reached consensus on the appropriate patch for core/rc, but I'm not sure what changes are needed for lvm2 or sysvinit.
<ukky> core/sysvinit does not depend on content of core/rc. On my amd64+glibc system sysvinit is not installed, core/rc is installed but not used.
<ukky> core/rc must have a hard dependency on core/sysvinit, as /etc/inittab is handled only when sysvinit is installed.
<farkuhar> Last time I used LVM2, it was in the context of disk encryption (full-disk or single-partition, I can't remember). But it's not obvious how to translate that experience into a patch for lvm2 to make it work with non-eudev installations.
<ukky> I never used LVM2, not sure I can help. On my systems I have these for lvm2: --disable-udev_sync --disable-udev_rules
<ukky> And I have the same options patch for libdevmapper
Olutmies has joined #opencrux
<Olutmies> Remiliascarlet I asked this big boobed big woman for assistance. In such a sweet voice says "You want to have sex with me?"
<Olutmies> I replied "Hahahaha no, I am married. I am just trying to find a toilet" then replied in a deep manly voice. " Toilet is over there."
<Olutmies> After toilet I talked to him and took a photo. Hahahaha
<dlcusa> Ideally the CRUX Handbook can be expanded to help newbies figure out how to tersely address the various options the developers will not support. If not, OpenCRUX' Handbook can and helpfully provide a diff file.
<dlcusa> s/expanded * tersely/tersely * expanded/
dlcusa has left #opencrux [Leaving]
dlcusa has joined #opencrux
<Olutmies> There is two viral videos here in Malaysia dlcusa. Malay guy makes  a noose to catch a puppy and swing it around and throw it. Then takes stones. Large stones and hit the other puppies. This will end up in Islamic court
<dlcusa> IMHO it should end up in any court.
<Olutmies> It is disgusting behaviour so you are right, however they are under age dlcusa. It has to go to Islamic court
<dlcusa> Then the parents, too, IMHO.
<Olutmies> Basically 18 to 21  can be tried in court. But under age it needs to go to Islamic court
<Olutmies> 14 to 16 can be tried as an adult
<Olutmies> Here they think dogs are evil. But they never read the Quran
<dlcusa> “Either you deal with what is the reality, or you can be sure that the reality is going to deal with you.” --Alex Haley (author of Roots)
<Olutmies> Nice
<Olutmies>  Dlcusa I have a similar one "you either become part of the jungle or then jungle is going to take a part of you"
<Olutmies> Then/the*
<dlcusa> Yes, practically equivalent.
<dlcusa> The jungle is real.
<Olutmies> I actually teCh
<Olutmies> I actually teach that
<dlcusa> It's also non-apologetic. ;-)
<dlcusa> Related: "Dad, why don't we ever put anything in the offering plate?" "We're non-denominational."
<Olutmies> OHdh I got stories about that
zorz has quit [Quit: Lost terminal]
Olutmies has quit [Quit: Client closed]
Olutmies has joined #opencrux
Olutmies has quit [Client Quit]