<emmett1>
+1 from me for making independent fork of crux-musl
<emmett1>
centralize all crux-musl stuff in one place
<emmett1>
like issue, news, and etc in one place
<emmett1>
or atleast has its own core ports, CRUX (glibc) core ports has too much bullshit now
<emmett1>
and also switch init to runit? :D
<remiliascarlet>
SiFuh_: Just use CVS.
<remiliascarlet>
emmett1: I wouldn't be surprised if CRUX 3.9 will include Gnome via a Live CD, and becomes installable via Calamaris.
<remiliascarlet>
I mean the glibc one.
<SiFuh_>
emmett1: CRUX is a lightweight x86-64 Linux distribution targeted at experienced Linux users and delivered by a tar.gz-based package system with *BSD-style* initscripts.
<SiFuh_>
runit is not BSD-style
<emmett1>
remiliascarlet: Gnome in core repo? possible :D
<emmett1>
SiFuh_: CRUX is a lightweight x86-64 Linux distribution targeted at experienced Linux users and delivered by a tar.gz-based package system.
<emmett1>
:p
<SiFuh_>
emmett1: Well Per Liden wanted BSD-style scripts
<emmett1>
SiFuh_: just a suggestion..hehe
<emmett1>
i just love how runit handle services
<emmett1>
and good when handling service dependencies
<SiFuh_>
emmett1: I find all the links annoying
<SiFuh_>
emmett1: I asked the wife to buy 24 nuts. If not, I will just use the nuts I have on the Dyna Bolts here. So she comes back with only 4 Dyna Bolts. She really needs to learn to read.
<emmett1>
SiFuh_: or you need new wife?
<SiFuh_>
emmett1: A new wife would be the go
<emmett1>
SiFuh_: hahaa..+1 from me
<emmett1>
so you will not have miscommunication issue in the future
<SiFuh_>
emmett1: Yeah, should choose a Thai, Vietnamese or a Russian speaking wife so I won't have miscommunication
SiFuh_ has quit [Remote host closed the connection]
SiFuh_ has joined #crux-musl
<farkuhar>
What's the recommended way to satisfy the freedesktop spec for per-user runtime dirs, *without* linux-pam or that dumb_runtime_dir thing? If I put the mkdir command into ~/.xsession, then the parent directory can't be owner:group=root:root with mode 0755 (the way that /etc/rc currently creates /run/user/).
<farkuhar>
I was thinking to edit /etc/rc anyway, creating /run/user/ with owner:group=root:users and mode 1775, but maybe one of you has a better solution.
<remiliascarlet>
emmett1: I'd rather prefer the BSD-style initscripts thing. Just keep things simple, like how CRUX used to be.
<farkuhar>
runit uses per-service directories and symlinks to keep track of process state, much the same way that freedesktop insists on per-user directories for sharing data between programs. If runit directories and symlinks are veering too far from the KISS principle, then maybe I should also try leaving XDG_RUNTIME_DIR unset, and see which applications become crippled.
<farkuhar>
According to the freedesktop basedir spec, applications that need XDG_RUNTIME_DIR should issue a warning if this variable is unset. I'll have to check my xsession logs to see which applications start complaining, with XDG_RUNTIME_DIR unset.
<farkuhar>
Hmm, pid files and start-stop-daemon receive some harsh criticism ("prone to failures by design") from the runit authors. https://smarden.org/runit/benefits
<farkuhar>
On CRUX at least, I haven't encountered any of these shortcomings in sysvinit service scripts, so I'm not inclined to replace what isn't broken. But if the BSD-style initscripts can be made even simpler (borrowing ideas from OpenBSD perhaps?), I'm in favor of such a rewrite.
<farkuhar>
So to the extent that BSD-style initscripts are relying on start-stop-daemon, we should make sure that someone is caring for start-stop-daemon with the same attentiveness that stenur gave.
<farkuhar>
Maybe it was a unique period in the development of start-stop-daemon, that explains why stenur pushed so many commits between 2019 and 2022. These days the code has reached maturity and doesn't need as much maintenance?
<farkuhar>
But if start-stop-daemon is really "prone to failures by design" as the runit authors allege, and we decide to abandon sysvinit scripts due to the lack of maintainership for start-stop-daemon, then at least we have local expertise in runit (ukky, emmett1, zorz) to facilitate the transition.
<SiFuh_>
farkuhar: zorz? Bahahahahaha
<SiFuh_>
You forgot me, who used runit for years.
<farkuhar>
SiFuh_: didn't mean to forget you. Which distro gave you all those years of runit experience, anyway?
<SiFuh_>
Void
<farkuhar>
This opt/fdm commit message now has me curious ... why link to libbsd, if the program runs fine without it? It's like what they did with cups and linux-pam. Whenever a port gets moved to core, they seem to think everything that *can* use it *should* use it.
<farkuhar>
I know there's only a 4-week grace period when 3.7 repos are still receiving updates, but the eager linking between opt/fdm and libbsd cannot be back-ported to 3.7, where libbsd is still in contrib. It would make things easier just to forego any linking with libbsd, as frinnst recommended.
<SiFuh_>
remiliascarlet: Oh yeas, I used runit in Artix too
<farkuhar>
The opt/fdm commit only added a configure flag for libpcre2, not for libbsd. So it should continue to build just fine on CRUX 3.7, even if the contrib repo is disabled and the libbsd dependency cannot be found.
<farkuhar>
Endowing prt-get with the ability to consider optional dependencies (when sorting the install or update targets) would have allowed jue to demote libbsd to Optional, rather than a hard dependency. Users who have it installed (under a standard path) can reap the benefits that libbsd provides, but fdm should compile equally well without it (or when libbsd is installed under /usr/opt as in CRUX 3.7).
<farkuhar>
I guess it was through rose-tinted glasses that I claimed not to have encountered any of the shortcomings in sysvinit service scripts (alleged by the authors of runit), specifically the guesswork involved with pidfiles. Here's my old complaint about /etc/rc.d/crond: https://libera.irclog.whitequark.org/crux/2024-09-13#1726247793-1726249567;
SiFuh has quit [Remote host closed the connection]
SiFuh has joined #crux-musl
zorz_ has joined #crux-musl
<zorz_>
ukky ... 'lo
<farkuhar>
What impressed me so much when I first installed CRUX was how quickly it booted. The BSD-style initscripts made it perfectly transparent (to a newbie) what was happening during startup. I prefer to keep that simplicity, rather than switching to runit (where some of the implementation details might remain hidden from the novice user).