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