<illiliti>
testuser[m]: i would use awk only as a last resort
<illiliti>
also speed of while read depends on shell
fitrh has joined #kisslinux
<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
<testuser[m]>
this breaks toybox cp
<testuser[m]>
reproducible code is in the manpage itself
<illiliti>
hm
<illiliti>
works for me on zfs
sereg has joined #kisslinux
<testuser[m]>
yea its per filesystem thing
<testuser[m]>
clarified on #musl
<testuser[m]>
so bad
<wael[m]>
btrfs moment
<testuser[m]>
no
<wael[m]>
what moment is it
<testuser[m]>
linux moment
<wael[m]>
linux moment
<illiliti>
i think toybox should implement proper fallback
<wael[m]>
how am I supposed to continue even trying toybox now if cp can't even cp
<testuser[m]>
its all filesystems moment that are not in (nfs, fuse, cifs, ceph)
<testuser[m]>
grep -r '.copy_file_range = ' fs/
<testuser[m]>
and zfs*
<testuser[m]>
illiliti: btw why do you use zfs? any specific features you require?
<illiliti>
its encryption is faster than luks
<illiliti>
also zfs is the only way to have FDE without lvm
<illiliti>
lvm is crap, i hate it
<illiliti>
that's main reasons. i think i also should mention that i never had data corruption with zfs
<testuser[m]>
sounds good
<illiliti>
unlike luks+<put your in-tree fs>
<illiliti>
yeah that's surprising, any in-tree fs supposed to be more stable, but in fact it isn't
rohan has quit [Ping timeout: 268 seconds]
rohan has joined #kisslinux
rohan has quit [Ping timeout: 260 seconds]
rohan has joined #kisslinux
phinxy has quit [Ping timeout: 265 seconds]
phinxy has joined #kisslinux
fitrh has quit [Quit: fitrh]
rohan has quit [Ping timeout: 250 seconds]
ella-0 has joined #kisslinux
ella-0_ has quit [Ping timeout: 265 seconds]
<wael[m]>
TIL about expand(1p)
<wael[m]>
converts tabs to spaces
<testuser[m]>
illiliti: why exactly is it required to temporarily run and kill mdev during boot?
<testuser[m]>
If the service is going to be started anyway
rohan has joined #kisslinux
rohan has quit [Ping timeout: 265 seconds]
rohan has joined #kisslinux
<illiliti>
because service manager would run device manager asynchronously
<illiliti>
which might lead to race condition and broken permissions in /dev and other nasty stuff
<illiliti>
i know this shit looks like a hack
<illiliti>
but since we don't use systemd, where init and service manager are merged, we can't do better
<illiliti>
this could be a less hacky if there were a portable way to passthrough the control of existing process to service manager
<illiliti>
this way we could avoid killing device manager
<illiliti>
to be clear, we can't make this situation better without hardcoding non-portable things
an3223 has quit [Ping timeout: 258 seconds]
an3223 has joined #kisslinux
<testuser[m]>
Hmm
<testuser[m]>
Thoughts about switching to s6?
<wael[m]>
Yes
<wael[m]>
its very good excluding the fact it needs skalib and execline
<testuser[m]>
Bruh do u even know what s6 is
<wael[m]>
pretty damn good service manager or something
<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
<testuser[m]>
U mean that as an artix packaging thing right
<testuser[m]>
Useful things being systemd
<wael[m]>
artix has packages that are for the init installed in the system, like networkmanager-s6 for example
<wael[m]>
unless you use arch repos ontop of artix's
<noocsharp>
yeah, it's an artix/arch problem not an s6 one
<testuser[m]>
s6 is good for everything nontrivial like dependencies and stuff, but UX is confusing compared to runit
<illiliti>
s6 is nice, but if we're going to switch, should we keep init agnostic?
<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
<illiliti>
or support s6 as a sole provider?
<testuser[m]>
Maybe busy box bug or something
<testuser[m]>
Things get hackier the more generic you try to make them
<testuser[m]>
s6 also has a catchall logger so every single service is logged regardless of an explicit logger
<illiliti>
what about service files
<testuser[m]>
they can be mostly reused
<illiliti>
it's a lot of work to make them generic
<testuser[m]>
They're reusable apart from the directory they're put in
<testuser[m]>
like u can sym link run files to s6 "up" file
<illiliti>
what if service need more functionality than just "run and forget"
<illiliti>
e.g dependencies
<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
<testuser[m]>
deps will be handled by individual sv manager
<testuser[m]>
But this is a problem if sv manager doesn't have that concept
<illiliti>
maybe we should just keep things simple?
<illiliti>
hardcode one provider but keep scripts simple, so user can replace e.g s6 with runit
<illiliti>
no need for configuration, frameworks and stuff
<illiliti>
yes, one would have to fork init for that
<illiliti>
and rewrite it a bit
<testuser[m]>
We can do that minus the forking init part by making it into more functions
<illiliti>
i don't see how it would help
chomwitt has quit [Ping timeout: 268 seconds]
<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
<testuser[m]>
or mount /run because your init already does that
<illiliti>
i see
<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
<testuser[m]>
tho with s6 everything would be rewritten
<testuser[m]>
If it has to be idiomatic
<illiliti>
but still i think that having single provider would be a lot simpler
<testuser[m]>
like a single oneshot for each thing, eg devtmpfs, tmpfs, procfs etc.
<testuser[m]>
But that seems unnecessary
<testuser[m]>
Core stuff should be available before starting services
<testuser[m]>
I mean all we have to do is change stuff like "log Killing everything; { kall 9; }" into `killall() { log "..."; kall ...; }`
<testuser[m]>
I'll make POC tomorrow
<testuser[m]>
For clearing it up
<illiliti>
look what i mean
<illiliti>
single provider(e.g s6) is better since we don't have to maintain all of this agnostic stuff
<illiliti>
that would make init simpler and easier to understand, and it is actually KISS because user can easily fork it and make changes
<illiliti>
direct support for multiple providers is too much complexity
<illiliti>
you would have to be too "generic", that won't be KISS anymore
rohan has quit [Ping timeout: 264 seconds]
rohan has joined #kisslinux
<illiliti>
with single provider, we only guarantee that init will be simple
<illiliti>
with multiple providers, we need configuration, frameworks, "genericness"
<illiliti>
it's way too complex
<illiliti>
it's also related to device manager, since it has same problem
rohan has quit [Ping timeout: 265 seconds]
<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, ...
rohan has joined #kisslinux
<testuser[m]>
Making init scripts into sort of a library
<testuser[m]>
Only the bare minimum i.e whatever is present in current init, not services or anything
<wael[m]>
testuser: have you taken a look at sysmgr?
rohan has quit [Ping timeout: 265 seconds]
rohan has joined #kisslinux
<illiliti>
porting is easy if things will be kept simple and hackable
<wael[m]>
dilyn: why is toybox init unable to run /lib/init/rc.boot? if simply says its unable to run
<illiliti>
forking is a perfectly valid approach here
<illiliti>
we can even have default configurations for various inits as branches
<illiliti>
e.g runit branch for runit support and so on
<illiliti>
user just fork baseinit and change branch
<illiliti>
imho this is very kiss approach
rohan has quit [Ping timeout: 260 seconds]
<testuser[m]>
Hmm yeah, it allows to be more idiomatic too, according to init in use
<testuser[m]>
init is like 50 lines of shell
<testuser[m]>
i mean the scripts
<illiliti>
yeah that's why configuration doesn't make sense
<illiliti>
kiss is source-based. forking is easy here. we should exploit this
chomwitt has joined #kisslinux
<testuser[m]>
illiliti: then what about device manager udev configs
<illiliti>
i've changed my mind, as you see
<illiliti>
i no longer think that we should support all possible device manager
<illiliti>
by default - e.g via configuration
<illiliti>
we should switch to mdevd as a sole provider of device manager
<wael[m]>
just support the 'KISS'iest one and go with it
<wael[m]>
mdevd, the one by creator of s6?
<illiliti>
yep
<wael[m]>
if we are going to switch to s6 might as well do the same for mdevd since dependencies
<illiliti>
mdev.conf is simple enough, really. there's no reason to have abstraction over it
<illiliti>
everyone who uses different device manager, can easily convert it to their format
<wael[m]>
I love my smdev
<illiliti>
keep using it
<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
<wael[m]>
illiliti: why
<illiliti>
what why? smdev is fine as device manager. if you'd like to use it, there's no lock-in
<wael[m]>
fair
<illiliti>
we should just keep things simple, so user can easily fork and switch components of the system
<illiliti>
that's all we should care about. we shouldn't care about emulation, abstraction, configuration and all of this
<wael[m]>
what about the rc.conf that baseinit used to utilize?
<testuser[m]>
What was that even used for lol
<illiliti>
to configure which service manager to use
<illiliti>
we should drop it
<illiliti>
unless it's used for something else
<testuser[m]>
Um that file doesn't seem to be used at all in init -- no `var:-default` or `var:=default ` in scripts
<illiliti>
it's used in master branch
an3223 has quit [Ping timeout: 258 seconds]
an3223 has joined #kisslinux
<testuser[m]>
Do kiss alternatives break if file contains ">" in name?
<illiliti>
perhaps
ehawkvu has joined #kisslinux
<testuser[m]>
So bad
<testuser[m]>
Shell moment
<testuser[m]>
I think there would be a ton of such bugs
rohan has joined #kisslinux
rohan has quit [Ping timeout: 265 seconds]
rohan has joined #kisslinux
<ehawkvu>
I figured out a solution to the VERSION markers