Notices by anna (navi@social.vlhl.dev)
-
Embed this notice
anna (navi@social.vlhl.dev)'s status on Friday, 02-May-2025 22:28:34 JST 
anna
why'd no one at my house ever made salad with salt and pepper before
salad is actually *good* like that, huh -
Embed this notice
anna (navi@social.vlhl.dev)'s status on Friday, 02-May-2025 22:28:32 JST
anna
@lizzy i'm not a fan of sour tastes though so vinegar and mustard is difficult, olive oil i use sometimes -
Embed this notice
anna (navi@social.vlhl.dev)'s status on Wednesday, 30-Apr-2025 02:57:20 JST
anna
@lanodan oh new game, i watched the anime ages ago -- maybe i should pick up the manga asw once i get a new e-reader -
Embed this notice
anna (navi@social.vlhl.dev)'s status on Tuesday, 29-Apr-2025 23:55:46 JST
anna
@scathach @lizzy i am a what now -
Embed this notice
anna (navi@social.vlhl.dev)'s status on Tuesday, 29-Apr-2025 23:55:21 JST
anna
@scathach @lizzy @kimapr
i like writing modern c and would very much like not being called that -
Embed this notice
anna (navi@social.vlhl.dev)'s status on Tuesday, 29-Apr-2025 23:21:06 JST
anna
@nao i mean B is literally the predecessor of C, by Ken and Dennis as well: https://en.wikipedia.org/wiki/B_(programming_language) -
Embed this notice
anna (navi@social.vlhl.dev)'s status on Tuesday, 29-Apr-2025 19:20:18 JST
anna
do not walk an hour in the treadmill without shoes on
got it, also ouch -
Embed this notice
anna (navi@social.vlhl.dev)'s status on Saturday, 26-Apr-2025 17:24:25 JST
anna
@lanodan the issue is that at least outside bsd-targeted software, i don’t really see things calling daemon(), but instead, double fork() + setsid(), and those can’t really be no-op’d
-
Embed this notice
anna (navi@social.vlhl.dev)'s status on Saturday, 26-Apr-2025 17:23:00 JST
anna
okay, i found *another* script that runs multiple daemons, dropbox's on gentoo, loops over DROPBOX_USERS and starts a daemon for each of them
it should instead, obviously, multiplex itself for each user instead of... *broad pointing gesture* this. -
Embed this notice
anna (navi@social.vlhl.dev)'s status on Saturday, 26-Apr-2025 17:15:19 JST
anna
that's new, service starts itself manually, by calling it's own, i assume self-daemonizing, binary
but then uses start-stop-daemon to stop via a self-written pidfile
not only, "why", but also that means s-s-d won't have a cmdline to compare against should the pidfile be wrong
gah -
Embed this notice
anna (navi@social.vlhl.dev)'s status on Saturday, 26-Apr-2025 17:13:37 JST
anna
@kimapr @ada
portage is not transactional due to the issue of, you need an updated libfoo, to build the updated nya package, so libfoo is updated, replaces the old version on disk, but then nya fails to build, and the old nya on disk would no longer have the libraries it needs, thus broken
it's the same issue as "nya didn't update" on arch, but gentoo has the safety net of preserved libs -
Embed this notice
anna (navi@social.vlhl.dev)'s status on Saturday, 26-Apr-2025 17:13:34 JST
anna
@kimapr @ada not that i know of, it does build with a network and filesystem sandbox, so packages can't poke outside of their $WORKDIR, but it's not a chroot -
Embed this notice
anna (navi@social.vlhl.dev)'s status on Saturday, 26-Apr-2025 17:13:32 JST
anna
@ada @kimapr i honestly forgot that breaking the sandbox is allowed in some ways
it'll be painful to make the virtual BROOT work seamlessly won't it -
Embed this notice
anna (navi@social.vlhl.dev)'s status on Saturday, 26-Apr-2025 17:07:37 JST
anna
@kimapr @ada .so reference is a fallback, or, "fuck something went wrong better keep those around for a while"
it's more important on gentoo if you're running ~testing packages because compilation on those can fail, which would leave you with a package still linked to an old dep version -
Embed this notice
anna (navi@social.vlhl.dev)'s status on Saturday, 26-Apr-2025 17:07:34 JST
anna
@ada @kimapr i do want to have a virtual build root for packages in my portage impl tbh
not only for transactional updates, but also so that packages in your live system not declared in {B,}DEPEND don’t affect the build (usually due to automagical dependency checks, aka dependency('foo', required: false);)
-
Embed this notice
anna (navi@social.vlhl.dev)'s status on Saturday, 26-Apr-2025 16:56:26 JST
anna
command=/usr/bin/java
command_args="-jar $INSTALL_DIR/svc.jar"
idk why but this is amusing to me, like, no wrapper/launcher script? aight' -
Embed this notice
anna (navi@social.vlhl.dev)'s status on Saturday, 26-Apr-2025 07:57:57 JST
anna
@ska
> Are you sure it's how OpenRC has been thought out so far, or that it's a direction you want to take it in and you can do it without breaking a lot of assumptions?
so far we have, start-stop-daemon that does not care how many daemons you start, and supervise-daemon which technically doesn't care but it uses the same "options" dir which means some settings and values (like cmdline and start time) override each other (which, not good)
tho librc has this rc_daemon api that is meant to manage serveral daemons per service doing pid and cmdline matching, with `/run/openrc/daemons/$service/%03d` folders for each daemon... but in reality i only ever see 001 in there, with the exception of the deprecated tigervnc script (the new script uses symlinks, so different logical services)
so... start-stop-daemon seems to have been written in the past with multiple daemons in mind, while supervise-daemon was written with start-stop-daemon as a base but completely ignoring the multiple daemons
--
as what direction to do from here, i'm not sure. having daemons/processes be 1:1 with services, makes things simpler, but it does take away one "feature" of start-stop-daemon
let's define optionsdir to /run/openrc/options/$service and daemondir to /run/openrc/daemons/$service
i can go either way, if i make it 1:1, i remove the %03d from the daemondir, and it becomes a single unified dir for supervision "runtime" (sockets/fifo), and i simply use /run/openrc/options to store the supervision state (child_pid, cmdline, respawn options, notify-fd settings)
if i make it 1:N, i keep the %03d subdirs per daemon, move all per-supervise-daemon option from the optionsdir to the daemondir/$id, and have the `status` output iterate all daemons and print info for all of them (tho i'm unsure which "runtime" `rc-status` would print in the summary page)
and this is where i'm at right now. current openrc is a mess of "it works, but it also doesn't, depending on the codepath" and my job is to make sense of this mess... -
Embed this notice
anna (navi@social.vlhl.dev)'s status on Tuesday, 22-Apr-2025 21:11:32 JST
anna
one day i'll re-watch saint seiya
tho part of me wants to watch it in the original japanese, and part of me wants to watch it in the ptbr dub because nostalgia ~w~
(the ptbr version of pegasus fantasy rocks) -
Embed this notice
anna (navi@social.vlhl.dev)'s status on Monday, 21-Apr-2025 07:29:59 JST
anna
@leo @puppygirlhornypost2 @wyatt
meson: uses pkg-config to attempt to locate a dependency (optionally can attempt that weird cmake format)
if that fails, attempt to download and build the dependency from a wrap file, if such file is available
if that fails, then it tells the user "can't find dependency"
that's, how you do it. integration with native first, download+build as a last resort -
Embed this notice
anna (navi@social.vlhl.dev)'s status on Monday, 21-Apr-2025 07:09:00 JST
anna
@puppygirlhornypost2 meson unless you have a very niche usecase
All GNU social JP content and data are available under the