| rossignol | rwp, and golinux - thanks. I think I found a bunch of it in /etc/update-motd.d/ | 00:18 |
|---|---|---|
| debdog | drizzt: yes, of course. that's implied, isn't it? using any shell without auto-completions would be a horrible experience | 01:05 |
| drizzt | not really | 01:09 |
| drizzt | I stopped using it some time ago, when it kept trying to do what I didn't want, and did not do what I wanted | 01:10 |
| drizzt | not to say that when i made the mistake of using "Tab" on a command line for scp I had to wait till the timeout for it trying to ask the remote host for completion .... | 01:12 |
| drizzt | I finally chose to use my head to learn the options for the commands, and to use man extensively | 01:13 |
| debdog | one does not exclude the other | 01:14 |
| Xenguy | Suit yourself, but I'll take my shell's auto completions, and I'll take the reverse search (Ctrl-r) as well. Now *that's* a civilized command-line experience : -) | 02:31 |
| freem | <drizzt> not to say that when i made the mistake of using "Tab" on a command line for scp I had to wait till the timeout for it trying to ask the remote host for completion .... | 03:08 |
| freem | at least with zsh you can ctrl+c those. Helps a lot with git... | 03:08 |
| rwp | Control-C did not interrupt that? It usually does interrupt it for me. But I never use scp because I always use rsync, which has every possible feature and then three more in addition. | 05:13 |
| Alverstone | freem, https://paste.debian.net/plain/1332356 | 15:10 |
| Alverstone | didn't touch rcS.d's udevd startup script | 15:11 |
| Alverstone | if i don't start it early console setup doesn't apply and the font tears my eyes out | 15:11 |
| freem | yeah, I didn't modified the rcS.d one neither | 15:11 |
| Alverstone | wouldn't it start twice? i tried playing with no.emulate.sysv.d, but as I said console-setup doesn't work until udevd starts fully | 15:13 |
| Alverstone | doesn't make sense to hurt eyes, so I added the '[ -S' line to restart it | 15:13 |
| freem | what do you mean, start twice? | 15:13 |
| Alverstone | rcS.d starts udevd too, at least on my system | 15:14 |
| Alverstone | so my run script does 'udevadm control --exit' in case control socket exists | 15:14 |
| freem | what gives `ls -1 /etc/service /etc/init.d/*udev*`? | 15:15 |
| freem | in theory, if you name the runit service the same way the rc.d udev service is named, then the rc.d one won't be used, and thus you should only have one instance | 15:16 |
| Alverstone | freem, ah, I get you now | 15:16 |
| Alverstone | I called my runit script as eudev | 15:16 |
| freem | % upl /etc/runit/1 -k | 15:17 |
| freem | https://p.mort.coffee/vxg | 15:17 |
| freem | as you can see, there's some black magic done to handle rcS.d/S* stuff | 15:17 |
| freem | nothing really fancy, but that can still bite you when you're not aware :) | 15:17 |
| freem | (or if you are distracted for some reason... hapened to me more than once) | 15:18 |
| Alverstone | yes yes I know | 15:19 |
| Alverstone | the point | 15:19 |
| Alverstone | stage 1 doesn't ignore rcS.d services | 15:20 |
| freem | the only problem I have about fonts is that it is udev which loads the vesa or whatever thing that increases PTYs resolution, so the early logs are hard to get. I think I could work around that by somehow toying with initrd or something, but I don't know how to do that | 15:20 |
| Alverstone | only through no.emulate.sysv.d | 15:20 |
| freem | what's this? | 15:20 |
| Alverstone | so it starts eudev anyway | 15:20 |
| Alverstone | ?? | 15:20 |
| Alverstone | wait a sec | 15:20 |
| freem | oh, I never noticed that folder! | 15:20 |
| freem | wtf is this now | 15:20 |
| Alverstone | https://paste.debian.net/plain/1332360 | 15:20 |
| Alverstone | it isn't documented | 15:21 |
| Alverstone | I'd never know if I didn't read the scripts :D | 15:21 |
| freem | good catch, that line was not there in prev debian, I'm certain | 15:21 |
| freem | it was the default behavior though :) | 15:22 |
| Alverstone | are those scripts overridden on updates? | 15:22 |
| freem | yes, by dpkg, but it will show you the diff if you modified something and ask you which version to keep, defaulting on your modified one | 15:22 |
| Alverstone | i wish it was useful though | 15:23 |
| Alverstone | dpkg doesn't allow to save its new version somewhere so I inspect it later myself | 15:23 |
| freem | I suppose I lacked attention when I updated and didn't noticed that line. Or simply ignored it since things defaults to correct things | 15:23 |
| freem | sure it does | 15:23 |
| freem | actually... | 15:23 |
| freem | :/etc/runit% ls -lh | 15:23 |
| freem | total 44K | 15:23 |
| freem | -rwxr-xr-x 1 root root 944 27 juil. 2023 1 | 15:23 |
| freem | -rwxr-xr-x 1 root root 494 2 sept. 2021 1.dpkg-old | 15:23 |
| Alverstone | you install new version and old is kept | 15:23 |
| Alverstone | yeah | 15:23 |
| freem | looks like I did modified /etc/runit/1 :) | 15:23 |
| Alverstone | remembered | 15:23 |
| Alverstone | never touched 1 | 15:24 |
| Alverstone | modified 2 though | 15:24 |
| Alverstone | c=/dev/tty12 | 15:25 |
| Alverstone | exec <$c >$c 2>$c | 15:25 |
| Alverstone | added these two lines | 15:25 |
| freem | I did, because I'm using runit since many years, and it was not integrated at all initially | 15:25 |
| Alverstone | :) | 15:25 |
| Alverstone | a good thing Devuan supports runit now! | 15:25 |
| freem | honestly? It helps, sure, but the stuff is so simple to maintain that even if debian and devuan did not, I would still run it | 15:26 |
| Alverstone | freem, so, is udevd started early for you? if no, it is because you ignore entries in init.d when the same named service exists in /etc/service? | 15:26 |
| freem | define early | 15:26 |
| freem | I do have a moment where I have the low resolution of the early 90s | 15:26 |
| freem | but it eventually vanishes away after, perhaps, 2s? | 15:27 |
| freem | it's a bit annoying, but I never tried to fix it | 15:27 |
| freem | I suspect the *real* and *sane* solution would be to load the module through modprobe in /etc/runit/1, before anything else is done | 15:28 |
| Alverstone | which module though? | 15:28 |
| freem | only problem is, what would happen if said module was buggy for one reason or another? I don't know if that'd crash the kernel or not | 15:28 |
| Alverstone | does udev load kernel modules? i don't know how it works at all tbh | 15:29 |
| Alverstone | freem, early is stage 1 | 15:29 |
| freem | well, not having udev running around certainly prevents me to use random peripherals, depending on the computer | 15:29 |
| Alverstone | freem, I tried your script and blacklisted udev from stage 1 and I get crippled console, same thing you describe. Then, in stage 2, when udev eventually starts, I get my console "corrected" to its usual state | 15:31 |
| freem | as for "which module", in my case, it's likely i915, kvm_intel, this kind of stuff | 15:31 |
| Alverstone | I don't what exactly is done to cause this | 15:31 |
| freem | so we have the same behavior | 15:31 |
| Alverstone | basically, yes | 15:31 |
| Alverstone | >i915 | 15:32 |
| freem | I would have named "early" the initrd though | 15:32 |
| Alverstone | freem, depends on context :) | 15:32 |
| freem | I don't know if initrd spams logs, but it is likely | 15:32 |
| freem | I wish I could get rid of initrd, really | 15:32 |
| Alverstone | you know, I'll reboot now, with udev completely disabled and try loading i915 (i have intel too) to see if it matters | 15:33 |
| freem | you checked with lsmod that those modules are the ones you need? | 15:33 |
| Alverstone | no idea | 15:33 |
| Alverstone | :) | 15:33 |
| Alverstone | sec | 15:33 |
| freem | I'll try that quickly as well | 15:35 |
| freem | nope, that does not fix the problem for me, with kvm, kvm_intel, i915, drm_buddy, drm_display_helper and drm_kms_helper added to /etc/modules | 15:37 |
| freem | that stuff should be done by /etc/init.d/kmod though, which I guess is ran at /etc/runit/1 | 15:38 |
| freem | hm | 15:41 |
| * freem could use a tool to make a graph from lsmod's output | 15:43 | |
| freem | lsmod | mawk 'BEGIN{ print "digraph kernel_modules { " } END{ print "}" } { numdeps = split( $4, modules, "," ); for( i = 0; i < numdeps; ++i ){ if( modules[i] > 0 ) printf( "%s -> %s\n", $1, modules[i] ); } }' | dot -Tpdf | zathura - | 15:57 |
| freem | that one-liner works | 15:57 |
| freem | just needs lsmod, mawk, graphviz and zathura (or to tweak the line ofc) | 15:57 |
| freem | (and this shows that sound modules are a mess...) | 15:59 |
| freem | could try to load wmi and video as well I guess | 16:00 |
| freem | TIL: lsmod gives different results when running as root or not... I was not exactly expecting that | 16:02 |
| freem | anyway, I really suspect this modules loading needs to be done in initrd | 16:06 |
| freem | and I was right. The (partial, there are still some text printed in ugly font) solution is to add those modules in /etc/initramfs-tools/modules and then follow instructions in that file | 16:10 |
| freem | this have nothing to do with runit. | 16:10 |
| freem | and this is exactly why I would like to manage to make my system *not* depend on initrd, it just makes the boot sequence more complicated to understand for those willing to dive in the internals of their systems | 16:11 |
| freem | now, I wonder... maybe I should just take the output of lsmod and pour it into /etc/initramfs-tools/modules, that would nicely reduce the requirement to have udevd sitting around | 16:15 |
| Alverstone | freem, you're right | 16:16 |
| Alverstone | modprobe i915 | 16:16 |
| freem | as long as I have nothing plugged in, that is, obviously. But I rarely plug stuff in my desktop, network is more convenient | 16:16 |
| Alverstone | then | 16:16 |
| Alverstone | setupcon | 16:16 |
| Alverstone | and done | 16:16 |
| freem | oh | 16:16 |
| Alverstone | however! | 16:16 |
| Alverstone | a lot of scripts break | 16:16 |
| freem | I have another solution | 16:16 |
| Alverstone | brightness isn't reset | 16:16 |
| Alverstone | fuse isn't loaded | 16:17 |
| freem | https://p.mort.coffee/Ekl | 16:17 |
| freem | basically: <freem> and I was right. The (partial, there are still some text printed in ugly font) solution is to add those modules in /etc/initramfs-tools/modules and then follow instructions in that file | 16:17 |
| Alverstone | took me time because I rewrote getty-tty* services, they're too stupid | 16:17 |
| freem | I used to use a different getty a while ago, but I stopped, it barely provided any benefit | 16:18 |
| freem | it was ngetty I think? A daemon which would create ptys on demand, instead of keeping them all in memory for no reason. Also less features than agetty, notably no support for RS232 which is entirely useless on 99% modern systems | 16:18 |
| freem | rss usage was a lot smaller, as well. | 16:19 |
| freem | rss ram usage, as in `ps -orss,vsz,comm -A` | 16:19 |
| Alverstone | freem, run file: https://paste.debian.net/plain/1332370 | 16:19 |
| Alverstone | finish file: https://paste.debian.net/plain/1332371 | 16:19 |
| Alverstone | and just symlink as much as you want | 16:20 |
| Alverstone | so much more convenient | 16:20 |
| Alverstone | Lorenzo should make it default | 16:20 |
| freem | hehe yeah, i had some similar stuff | 16:20 |
| freem | % cat /etc/runit/common | upl | 16:21 |
| freem | https://p.mort.coffee/E66 | 16:21 |
| freem | I think that's the origin of this file, even: to avoid duplicating files to modify manually when their configuration is already included in their path | 16:21 |
| Alverstone | freem, I've saved your scripts, don't worry :) | 16:21 |
| freem | then I exanded that idea to all daemons, allowing me to have easy to grep messages to scan for executions of run and finish | 16:21 |
| freem | I should probably contribute them somewhere tbh | 16:22 |
| Alverstone | :) | 16:22 |
| freem | just dunno how, and I feel too lazy to register to a mailing list | 16:22 |
| freem | ideally I'd like to have a more complete ecosystem, with more tooling, and probably to toy with cgroups/namepsaces/etc | 16:23 |
| Alverstone | about initrd, afaik you have to compile kernel yourself, to make some necessary modules built into vmlinuz | 16:23 |
| freem | the fact the udev script is so ugly and fragile for example would be a good use case for namespaces | 16:23 |
| Alverstone | and then /etc/modules.d needs to be updated! | 16:23 |
| Alverstone | probably | 16:23 |
| freem | no, no need to recompile anything | 16:23 |
| Alverstone | but vmlinuz doesn't boot without initrd for some reason | 16:24 |
| freem | the actual boot sequence of most linux-based computers is: EFI -> grub -> initrd -> /sbin/init | 16:24 |
| Alverstone | didn't dig too deep | 16:24 |
| freem | on my system, one just replaces grub with syslinux, and add the constraint to run an update script after various updates | 16:24 |
| Alverstone | can't grub work without initrd? | 16:25 |
| freem | anyway, the role of initrd is to load modules required to continue the boot sequence. If you consider eye-candiness to be required, it have it's place here | 16:25 |
| Alverstone | i remember somebody did no initrd with grub | 16:25 |
| freem | grub can execute the kernel directly, yes | 16:25 |
| Alverstone | very easy setup | 16:25 |
| Alverstone | dunno why it didn't work for me | 16:26 |
| freem | same for syslinux/lilo/whatever actually... but I'm a bit afraid to try that | 16:26 |
| freem | anyway, I remember many, many things are embedded into initrd, including udev's binary | 16:27 |
| Alverstone | yep it's pretty fat | 16:27 |
| freem | oh, yes it is | 16:27 |
| freem | you can't even use the default initrd if your system have less than 200 megs of ram, such as virtual machines! | 16:27 |
| freem | and this, despite the fact the booted system only requires less than 100megs with all daemons up :) thankfully there are now packages which address this issue, but I'm still not fond of using this giant black box on my systems | 16:28 |
| freem | I know it have some uses, for example it allows one to encrypt / which would otherwise not be possible, but I think it's over-used, still | 16:29 |
| Alverstone | as i see it so long as systemd people rule the party nobody's gonna care about your ram. their advice is "it's cheap, just buy more" | 16:30 |
| freem | yeah | 16:31 |
| freem | that is also what my IT teachers taught to students, 20 years ago. For industry programming. You know, the kind in which changing a computer cost several 10K money... | 16:31 |
| freem | thankfully I was already a coder by then, so I was not infested by this stupidity | 16:32 |
| freem | when classmates were learning how to use poiners in C, I was learning to use templates... each one their rythm :) anyway, that is offtopic | 16:32 |
| freem | as for systemd, when I measured how many daemons I'd need to have for runit to use the same memory, it was more than 30. With the bad glibc6 build, because with a saner build (static linking or linking with muslc) it is more thann 1000 | 16:33 |
| Alverstone | I'm not a coder at all :) so I don't have anything to add | 16:33 |
| Alverstone | you use musl? | 16:33 |
| freem | not on this system, but I toyed with it | 16:33 |
| freem | and on a system which have memory contraints I can use busybox, which embeds it's own runsv and co | 16:34 |
| freem | if I could use only musl+libc++ I'd be a lot happier, really | 16:35 |
| freem | but their integration in debian is terribly bad, and actually worsened with time | 16:35 |
| freem | it seems those days maintainers love to fuck the FHS | 16:35 |
| freem | anyway, about runit, there are still a few tools I'd love to have, including some kind of monitor, would be handy to get a visual hint that a service is KO | 16:38 |
| gnarface | i think that's a feature s3 has | 16:39 |
| gnarface | s6 i mean, sorry | 16:39 |
| Alverstone | i have an important question | 16:39 |
| Alverstone | make oldconfig | 16:39 |
| Alverstone | if i just hit enter | 16:39 |
| Alverstone | does it select the default? | 16:39 |
| Alverstone | i don't wanna misconfigure my kernel :( | 16:40 |
| gnarface | it loads the old config | 16:40 |
| gnarface | i forget from where, exacxtly | 16:40 |
| gnarface | *exactly | 16:40 |
| Alverstone | and then prompts for new options | 16:40 |
| fsmithred | the configs are in /boot | 16:40 |
| gnarface | is that where it pulls them from though? for some reason i thought it pulled the old config from "$BUILDROOT/.config.old" or something like that | 16:42 |
| gnarface | i know you can get the installed configs from /boot | 16:42 |
| gnarface | on some distros you can also get the running config from /proc/config.gz but not with stock debian kernels | 16:43 |
| fsmithred | oh, it's been so long since I've compiled a kernel, I'm not sure. Mabye I copied it from /boot. | 16:44 |
| fsmithred | and I'm remembering compiling from debian source, not kernel.org source. That was much longer ago and is lost in the dust. | 16:45 |
| gnarface | hit might just load it from $BUILDROOT/.config like normal, but treat it differently.... hmm | 16:48 |
| fsmithred | ? | 16:49 |
| gnarface | ah, it does just load it from $BUILDROOT/.config like normal, but treat it differently, i think | 16:50 |
| gnarface | well, that's what my google search results say, and that matches at least one of the 3 conflicting memories on the matter | 16:51 |
| gnarface | so you would have to manually copy it there from somewhere else | 16:52 |
| gnarface | or, i think menuconfig might have a menu option for it too | 16:52 |
| Alverstone | freem, sv check /etc/service/* :D | 16:53 |
| fsmithred | I gotta go. bbl. | 16:53 |
| freem | gnarface: it likely have a tool for that, yes, but it also feels quite complicated as well. There is no reason to be unable to run (a wrapper above inotify/whatever bsd feature) on the logger's output (to handle file rotation) and to grep for some strings indicating status after all | 16:53 |
| freem | Alverstone: yes, I know, but you need to run this on periodical basis, manually. What I'd love to have is a tool that gives me some icon in i3bar showing when there's a problem, and which service is buggy | 16:54 |
| Alverstone | i3status? | 16:55 |
| Alverstone | do you use it? | 16:55 |
| Alverstone | or sth else? | 16:56 |
| freem | nope, I use i3blocks. I don't remember why this one though | 16:56 |
| Alverstone | i3blocks? | 16:56 |
| Alverstone | what's it | 16:56 |
| freem | an alternative to i3status :) | 16:56 |
| Alverstone | :) | 16:56 |
| Alverstone | i3status has read_file | 16:56 |
| Alverstone | make a cron job | 16:56 |
| freem | highly flexible status line for the i3 window manager | 16:56 |
| freem | Status line for the i3 window manager and i3bar that handles clicks, signals and language-agnostic user scripts. | 16:56 |
| Alverstone | a script | 16:57 |
| Alverstone | and a read_file | 16:57 |
| Alverstone | >highly flexible, user scripts, mouse | 16:57 |
| Alverstone | meh | 16:57 |
| freem | I suppose I use it for my mpd/sound control stuff | 16:57 |
| Alverstone | too complex | 16:57 |
| Alverstone | I figured i3status does everything I want | 16:57 |
| freem | I want my mpd stuff in that bar thuogh :) | 16:58 |
| Alverstone | ehh i don't use mpd though :) | 16:58 |
| Alverstone | do you launch a front end on a click or what? | 16:58 |
| freem | and IIRC I could not with i3status: https://p.mort.coffee/eYn.png | 16:59 |
| freem | I use ncmpc, a TUI interface, but I also have binds in i3, obviously | 16:59 |
| Alverstone | looks cool | 17:00 |
| freem | so I can change the track (webradios mostly) without grabbing the mouse, and I always know which song is on air | 17:00 |
| Alverstone | i'd probably just wrap around read_file and maybe i3ipc python module :) | 17:00 |
| freem | well, my system happens to be mostly python free, and I intend it to stay that way | 17:01 |
| Alverstone | or a script that reads from i3status and spits without modification, but uses that as an indicator that contents of files should be updated :) | 17:01 |
| Alverstone | could even get pango markup in there | 17:03 |
| freem | blender, kicad, mesa-vulkan-drivers, and few dev tools are the only stuff requiring python on my system, and it makes me happy. Would be better if I could entirely remove it, ofc, but those tools I use which require it are really useful, except for mesa-vulkan-drivers (plus, how can a damn driver depend on python?!?!) which I'm not even sure I use | 17:05 |
| freem | as for i3status, I used to have a C plugin for mpd I think, but it was too primitive, too limited. i3blocks is simply easier, despite it spawns processes periodically and is thus not optimal | 17:06 |
| freem | both those tools have their own limitations anyway. and if I'd make myself a monitor for runit, it would certainly not require any direct GUI library, better to just generate an image file, and get a script with inotify watching it for refreshes. Just need to find a proper tool to generate those, gnuplot is quite complicated for such simple matter | 17:09 |
| Alverstone | why do you dislike python though | 17:09 |
| freem | why would I like it? | 17:09 |
| Alverstone | it just werk | 17:09 |
| Alverstone | it just werks | 17:09 |
| Alverstone | seemingly :D | 17:10 |
| freem | not really. I no longer count the number of debian packages which have missing python dependences, so you have to go read the damn mess and toy with apt-file to guess which one is missing | 17:10 |
| gnarface | the python dependency in mesa-vulkan-drivers is probably because of this: /usr/bin/mesa-overlay-control.py | 17:10 |
| Alverstone | :) | 17:10 |
| gnarface | i couldn't really tell you what it's for though | 17:10 |
| freem | also, python is okayish for glue scripts, *not* for applications running all the time. Such applications should be written in native langs to avoid wasting perfs uselessly | 17:11 |
| freem | ah, thx, gnarface | 17:11 |
| freem | another good reason to dislike python: you can NOT trust their API to be stable | 17:11 |
| freem | it will randomly break between 2 versions, apparently | 17:12 |
| gnarface | heh, i do now suddenly find myself wondering if this is why the Steam overlay is so damned slow | 17:12 |
| Alverstone | a better scripting language that isn't shell tier miserable? | 17:12 |
| freem | there are awk, and perl, for thaat | 17:12 |
| Alverstone | perl :) | 17:12 |
| Alverstone | no thx | 17:13 |
| freem | I don't get the point to have 4 interpreted langs on my system | 17:13 |
| freem | you have to install perl on debian, it's a requirement. Unlike python. And I like my systems smaller, so I remove the one which is not required. | 17:13 |
| freem | mesa-overlay-control... might be related to the overlay mechanics in vulkan (a tool to add debugging info at runtime without increase CPU cost too much, from what I have read) | 17:16 |
| freem | I *suppose* this script is about extracting those overlay info from some mesa socket, from the very scarse information (and this does not even have a man-page...) | 17:17 |
| freem | lol | 17:18 |
| freem | python just works, heh? | 17:18 |
| freem | % /usr/bin/mesa-overlay-control.py --info | 17:18 |
| freem | [Errno 111] Connection refused | 17:18 |
| freem | % /usr/bin/mesa-overlay-control.py -info | 17:18 |
| freem | usage: mesa-overlay-control.py [-h] [--info] [--socket SOCKET] {start-capture,stop-capture} ... | 17:18 |
| freem | mesa-overlay-control.py: error: unrecognized arguments: -info | 17:18 |
| freem | then it's users should learn to use it... | 17:18 |
| freem | /rant | 17:19 |
| freem | (at least I didn't had to find out for a missing module this time) | 17:19 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
