[2022-10-06T02:21:56Z] hi [2022-10-06T04:54:56Z] Hi [2022-10-06T07:09:31Z] where did ioraff go [2022-10-06T07:10:09Z] oh he's back [2022-10-06T07:43:23Z] did he go inactive? [2022-10-06T09:09:19Z] is using awk forbidden in KISS [2022-10-06T09:09:39Z] pkg manager [2022-10-06T09:09:56Z] awk '{print $2}' is much faster than while read -r _ f2 [2022-10-06T09:24:51Z] https://codeberg.org/kiss-community/kiss/pulls/85/files [2022-10-06T09:42:10Z] how fast [2022-10-06T09:56:41Z] btw how does line 8 work in the PR? wouldn't it do for example a/manifest b c d e... [2022-10-06T09:57:26Z] also you can't do field argument with grep instead? [2022-10-06T10:06:39Z] splitting [2022-10-06T10:14:57Z] what [2022-10-06T10:15:09Z] yes is it not possible in grep [2022-10-06T10:42:17Z] illiliti: https://codeberg.org/kiss-community/init/commit/bcf5fbf8ab30c95d4c6a407d8afef1d0a50eddd2 ? [2022-10-06T10:42:21Z] was kall useless all along [2022-10-06T12:23:19Z] yes [2022-10-06T12:24:02Z] hi illiliti [2022-10-06T12:24:48Z] hi [2022-10-06T12:26:23Z] testuser[m]: i would use awk only as a last resort [2022-10-06T12:26:46Z] also speed of while read depends on shell [2022-10-06T12:40:19Z] illiliti: any idea why copy_file_range is broken? The manpage says "First support for cross-filesystem copies was introduced in 5.3. Older kernels will return -EXDEV when cross-filesystem copies are attempted." but im getting EXDEV on 5.19.9+ when copying from btrfs/ext4 to tmpfs [2022-10-06T12:40:26Z] this breaks toybox cp [2022-10-06T12:41:23Z] reproducible code is in the manpage itself [2022-10-06T12:46:12Z] hm [2022-10-06T12:46:17Z] works for me on zfs [2022-10-06T12:47:24Z] yea its per filesystem thing [2022-10-06T12:47:34Z] clarified on #musl [2022-10-06T12:48:10Z] so bad [2022-10-06T12:49:04Z] btrfs moment [2022-10-06T12:50:03Z] no [2022-10-06T12:50:18Z] what moment is it [2022-10-06T12:50:25Z] linux moment [2022-10-06T12:50:32Z] linux moment [2022-10-06T12:50:33Z] i think toybox should implement proper fallback [2022-10-06T12:50:59Z] how am I supposed to continue even trying toybox now if cp can't even cp [2022-10-06T12:51:16Z] its all filesystems moment that are not in (nfs, fuse, cifs, ceph) [2022-10-06T12:51:22Z] grep -r '.copy_file_range = ' fs/ [2022-10-06T12:51:27Z] and zfs* [2022-10-06T13:07:40Z] illiliti: btw why do you use zfs? any specific features you require? [2022-10-06T13:10:28Z] its encryption is faster than luks [2022-10-06T13:11:28Z] also zfs is the only way to have FDE without lvm [2022-10-06T13:11:54Z] lvm is crap, i hate it [2022-10-06T13:15:30Z] that's main reasons. i think i also should mention that i never had data corruption with zfs [2022-10-06T13:16:05Z] sounds good [2022-10-06T13:16:08Z] unlike luks+ [2022-10-06T13:17:18Z] yeah that's surprising, any in-tree fs supposed to be more stable, but in fact it isn't [2022-10-06T15:27:56Z] TIL about expand(1p) [2022-10-06T15:27:57Z] converts tabs to spaces [2022-10-06T15:31:41Z] illiliti: why exactly is it required to temporarily run and kill mdev during boot? [2022-10-06T15:32:13Z] If the service is going to be started anyway [2022-10-06T15:41:29Z] because service manager would run device manager asynchronously [2022-10-06T15:42:08Z] which might lead to race condition and broken permissions in /dev and other nasty stuff [2022-10-06T15:44:02Z] i know this shit looks like a hack [2022-10-06T15:45:00Z] but since we don't use systemd, where init and service manager are merged, we can't do better [2022-10-06T15:46:00Z] this could be a less hacky if there were a portable way to passthrough the control of existing process to service manager [2022-10-06T15:46:11Z] this way we could avoid killing device manager [2022-10-06T15:47:22Z] to be clear, we can't make this situation better without hardcoding non-portable things [2022-10-06T15:52:23Z] Hmm [2022-10-06T15:59:04Z] Thoughts about switching to s6? [2022-10-06T16:01:21Z] Yes [2022-10-06T16:01:46Z] its very good excluding the fact it needs skalib and execline [2022-10-06T16:06:44Z] Bruh do u even know what s6 is [2022-10-06T16:07:01Z] pretty damn good service manager or something [2022-10-06T16:08:56Z] i've been using artix s6 since i moved away from kiss and it's worked fine, barring the fact that many useful things are systemd services [2022-10-06T16:09:27Z] U mean that as an artix packaging thing right [2022-10-06T16:09:45Z] Useful things being systemd [2022-10-06T16:10:25Z] artix has packages that are for the init installed in the system, like networkmanager-s6 for example [2022-10-06T16:10:30Z] unless you use arch repos ontop of artix's [2022-10-06T16:10:49Z] yeah, it's an artix/arch problem not an s6 one [2022-10-06T16:12:05Z] s6 is good for everything nontrivial like dependencies and stuff, but UX is confusing compared to runit [2022-10-06T16:12:12Z] s6 is nice, but if we're going to switch, should we keep init agnostic? [2022-10-06T16:12:30Z] Also it's not clunky at all, like with runit if I'd restart a user's runsvdir, all subprocess would just get orphaned or something [2022-10-06T16:12:38Z] or support s6 as a sole provider? [2022-10-06T16:12:39Z] Maybe busy box bug or something [2022-10-06T16:13:21Z] Things get hackier the more generic you try to make them [2022-10-06T16:13:30Z] Look at dylan's current branch [2022-10-06T16:14:01Z] yep, hence my question [2022-10-06T16:14:17Z] this approach is better https://github.com/kisslinux/repo/pull/325#issuecomment-913930319 [2022-10-06T16:14:27Z] Still won't be plug and play [2022-10-06T16:14:29Z] but better [2022-10-06T16:17:39Z] s6 as default + modular scripts [2022-10-06T16:18:04Z] s6 also has a catchall logger so every single service is logged regardless of an explicit logger [2022-10-06T16:18:06Z] what about service files [2022-10-06T16:18:18Z] they can be mostly reused [2022-10-06T16:18:24Z] it's a lot of work to make them generic [2022-10-06T16:18:58Z] They're reusable apart from the directory they're put in [2022-10-06T16:19:18Z] like u can sym link run files to s6 "up" file [2022-10-06T16:20:21Z] what if service need more functionality than just "run and forget" [2022-10-06T16:20:27Z] e.g dependencies [2022-10-06T16:26:56Z] Then only dependencies part needs to be duplicated, eg in docker it needs cgroups. So the generic launch script can just do `cgroups_mounted || error` and [2022-10-06T16:27:19Z] deps will be handled by individual sv manager [2022-10-06T16:27:26Z] But this is a problem if sv manager doesn't have that concept [2022-10-06T16:27:43Z] maybe we should just keep things simple? [2022-10-06T16:28:13Z] hardcode one provider but keep scripts simple, so user can replace e.g s6 with runit [2022-10-06T16:28:30Z] no need for configuration, frameworks and stuff [2022-10-06T16:30:10Z] yes, one would have to fork init for that [2022-10-06T16:30:38Z] and rewrite it a bit [2022-10-06T16:32:32Z] We can do that minus the forking init part by making it into more functions [2022-10-06T16:34:45Z] i don't see how it would help [2022-10-06T16:39:17Z] eg u might not want to run hooks in /etc/rc.d, or not run an emergency shell when every command fails because your init system already has a better mechanism for that [2022-10-06T16:39:26Z] or mount /run because your init already does that [2022-10-06T16:41:52Z] i see [2022-10-06T16:42:02Z] Like I'm running s6 but I can't run rc.shutdown verbatim cuz it not only unmounts swap, but also handles sending of sig term / kill [2022-10-06T16:42:20Z] tho with s6 everything would be rewritten [2022-10-06T16:42:29Z] If it has to be idiomatic [2022-10-06T16:42:34Z] but still i think that having single provider would be a lot simpler [2022-10-06T16:42:50Z] like a single oneshot for each thing, eg devtmpfs, tmpfs, procfs etc. [2022-10-06T16:42:51Z] But that seems unnecessary [2022-10-06T16:43:22Z] Core stuff should be available before starting services [2022-10-06T16:44:24Z] I mean all we have to do is change stuff like "log Killing everything; { kall 9; }" into `killall() { log "..."; kall ...; }` [2022-10-06T16:45:44Z] I'll make POC tomorrow [2022-10-06T16:45:44Z] For clearing it up [2022-10-06T16:46:34Z] look what i mean [2022-10-06T16:46:41Z] single provider(e.g s6) is better since we don't have to maintain all of this agnostic stuff [2022-10-06T16:46:53Z] that would make init simpler and easier to understand, and it is actually KISS because user can easily fork it and make changes [2022-10-06T16:47:29Z] direct support for multiple providers is too much complexity [2022-10-06T16:48:23Z] you would have to be too "generic", that won't be KISS anymore [2022-10-06T16:51:23Z] with single provider, we only guarantee that init will be simple [2022-10-06T16:51:32Z] with multiple providers, we need configuration, frameworks, "genericness" [2022-10-06T16:51:49Z] it's way too complex [2022-10-06T16:53:23Z] it's also related to device manager, since it has same problem [2022-10-06T16:55:42Z] Yea I agree with you, I'm not pushing for direct support of anything other than the default, just to make "porting" a little easier. Not adding any setup-specific hacks like case $mdev in udev mdev mdevd, or case $init in busybox, runit, s6, sinit, ... [2022-10-06T16:56:05Z] Making init scripts into sort of a library [2022-10-06T16:56:30Z] Only the bare minimum i.e whatever is present in current init, not services or anything [2022-10-06T16:59:34Z] testuser: have you taken a look at sysmgr? [2022-10-06T17:01:55Z] porting is easy if things will be kept simple and hackable [2022-10-06T17:03:04Z] dilyn: why is toybox init unable to run /lib/init/rc.boot? if simply says its unable to run [2022-10-06T17:03:25Z] forking is a perfectly valid approach here [2022-10-06T17:04:38Z] we can even have default configurations for various inits as branches [2022-10-06T17:04:52Z] e.g runit branch for runit support and so on [2022-10-06T17:05:10Z] user just fork baseinit and change branch [2022-10-06T17:05:37Z] imho this is very kiss approach [2022-10-06T17:14:56Z] Hmm yeah, it allows to be more idiomatic too, according to init in use [2022-10-06T17:15:08Z] init is like 50 lines of shell [2022-10-06T17:15:17Z] i mean the scripts [2022-10-06T17:24:27Z] yeah that's why configuration doesn't make sense [2022-10-06T17:24:53Z] kiss is source-based. forking is easy here. we should exploit this [2022-10-06T17:33:39Z] illiliti: then what about device manager udev configs [2022-10-06T17:36:02Z] i've changed my mind, as you see [2022-10-06T17:36:30Z] i no longer think that we should support all possible device manager [2022-10-06T17:36:50Z] by default - e.g via configuration [2022-10-06T17:37:18Z] we should switch to mdevd as a sole provider of device manager [2022-10-06T17:37:20Z] just support the 'KISS'iest one and go with it [2022-10-06T17:37:41Z] mdevd, the one by creator of s6? [2022-10-06T17:37:48Z] yep [2022-10-06T17:38:31Z] if we are going to switch to s6 might as well do the same for mdevd since dependencies [2022-10-06T17:41:27Z] mdev.conf is simple enough, really. there's no reason to have abstraction over it [2022-10-06T17:42:27Z] everyone who uses different device manager, can easily convert it to their format [2022-10-06T17:42:47Z] I love my smdev [2022-10-06T17:43:10Z] keep using it [2022-10-06T17:43:24Z] Ye I think we were going too much in the direction of accounting for all possible cases that could exist, not ones that actually do [2022-10-06T17:43:34Z] illiliti: why [2022-10-06T17:45:02Z] what why? smdev is fine as device manager. if you'd like to use it, there's no lock-in [2022-10-06T17:46:04Z] fair [2022-10-06T17:46:53Z] we should just keep things simple, so user can easily fork and switch components of the system [2022-10-06T17:47:55Z] that's all we should care about. we shouldn't care about emulation, abstraction, configuration and all of this [2022-10-06T17:51:38Z] what about the rc.conf that baseinit used to utilize? [2022-10-06T17:55:22Z] What was that even used for lol [2022-10-06T17:55:55Z] to configure which service manager to use [2022-10-06T17:56:00Z] we should drop it [2022-10-06T17:56:22Z] unless it's used for something else [2022-10-06T17:58:24Z] Um that file doesn't seem to be used at all in init -- no `var:-default` or `var:=default ` in scripts [2022-10-06T18:00:28Z] it's used in master branch [2022-10-06T18:42:45Z] Do kiss alternatives break if file contains ">" in name? [2022-10-06T18:51:19Z] perhaps [2022-10-06T18:57:40Z] So bad [2022-10-06T18:57:44Z] Shell moment [2022-10-06T18:58:11Z] I think there would be a ton of such bugs [2022-10-06T19:10:22Z] I figured out a solution to the VERSION markers [2022-10-06T19:11:12Z] https://raw.githubusercontent.com/ehawkvu/kiss-personal/master/bin/kiss-echecksum [2022-10-06T19:24:37Z] https://codeberg.org/kiss-community/repo/issues/120 [2022-10-06T19:26:02Z] you're faster than me :) [2022-10-06T19:33:49Z] https://codeberg.org/kiss-community/kiss/issues/87 [2022-10-06T22:35:57Z] o/ [2022-10-06T22:36:17Z] what would be the reason for /dev to be busy whenn mounting it on boot?