Notices by anna (navi@social.vlhl.dev), page 3
-
Embed this notice
anna (navi@social.vlhl.dev)'s status on Saturday, 12-Jul-2025 08:26:57 JST 
anna
@icedquinn what do you mean "control the build dir"? -
Embed this notice
anna (navi@social.vlhl.dev)'s status on Saturday, 12-Jul-2025 08:21:31 JST
anna
@icedquinn @bonifartius as long as you don't act in bad faith towards packagers, it'll all good
it's often that distro packagers find bugs and even open PRs to fix them (considering it's foss) -- packaging non foss is usually not allowed tho so for games that's usually the big problem
and meson is the only decent build system of the bunch :) -
Embed this notice
anna (navi@social.vlhl.dev)'s status on Saturday, 12-Jul-2025 08:16:54 JST
anna
@icedquinn @bonifartius don't package it for 20 distros, instead you use a standard, decent build system, list your dependencies clearly, package it for one distro, the one you use (or no distro if you don't use any)
then people that want your software in their distro will package it
flatpaks are fine as basically another distro to target, but the problem comes when upstream assumes flatpak is all that is valid to use and use that as an excuse to have a shit build system, and then screams about how everyone trying to package it for their distro is wrong and should use the dev-approved flatpak instead -
Embed this notice
anna (navi@social.vlhl.dev)'s status on Saturday, 12-Jul-2025 06:22:34 JST
anna
@lanodan @domi @weirdtreething @eloy
nop, it's actually the first target to be started (on non-gui systems):
> default.target
> The default unit systemd starts at bootup. Usually, this should be aliased (symlinked) to multi-user.target or graphical.target. See bootup(7) for more discussion.
https://www.freedesktop.org/software/systemd/man/latest/bootup.html# -> basically ever service daemon is started concurrently to getty@tty1 -- sysinit.target and basic.target are ran before multi-user, but it's the same in openrc with sysinit and boot -- daemons proper and other services are started in parallel to getty -
Embed this notice
anna (navi@social.vlhl.dev)'s status on Saturday, 12-Jul-2025 06:17:39 JST
anna
@lanodan @domi @weirdtreething @eloy
systemd's getty@.service has no After restriction at all, and they also print messages to the initial console, so i wonder what are they doing there (nothing related to getty.target either, except it being wanted by multi-user.target) -
Embed this notice
anna (navi@social.vlhl.dev)'s status on Saturday, 12-Jul-2025 05:54:41 JST
anna
@lanodan @domi @weirdtreething @eloy
there's a few things i'm planning to do to simplify this, improving rc parallel is the most important (if agetty is in default, and so is wpa, and wpa is not a dependency of agetty, then agetty should be able to just start in parallel)
then there's other things related to network specifically and better integration with network tools, though idk how exactly yet
also NetworkManager handles it a bit better by marking itself inactive until the connection is up later, wpa could do this but idk if it has such hooks -
Embed this notice
anna (navi@social.vlhl.dev)'s status on Friday, 11-Jul-2025 23:51:42 JST
anna
@aren @ska @lanodan
> And just to be clear, this is the problem I have with package managers in general, I'm not sure if it's what navi is trying to solve here.
i really like portage, i think it has some awesome concepts, but i really dislike it's python nature, obtuse configuration, and overall slooowness
and, since portage has an actual spec that is independent of it's implementation, this started as me wanting to write a implementation for it in c, serving as a faster, easier to configure, portage-like package manager, that i can hack features on easily to test concepts (ofc no hacks would make into releases, but more of playgrounds to polish ideas)
then i started to think of other package manager and issues, portage already avoids leaving the system in a broken state by `preserve-libs`, meaning a failed update always leaves libraries around that any package still uses -- but that isn't enough for me
i want to make the build and update process atomic, i don't want to touch the rootfs until everything is built and ready to install, being as atomic as possible at each step
at the same time i dislike most "immutable" distros, i don't want to mount / as read only, i don't want to reboot in order to apply a new update or add a package to my system set, i don't want to rely on out-of-tree container-based user-side package manager to add end-user programs
so i'm trying to make a traditional package manager in c, that follows the portage spec, is fast, correct, atomic, and does it's best to not allow chances of leaving the system in a broken, half-updated state -- i don't know if all of this is possible, but i'll try -
Embed this notice
anna (navi@social.vlhl.dev)'s status on Friday, 11-Jul-2025 07:57:13 JST
anna
00:15 <irc-nick> I just got to try openrc user services
00:16 <irc-nick> it's so good, thank you everyone who worked on the feature <3 -
Embed this notice
anna (navi@social.vlhl.dev)'s status on Friday, 11-Jul-2025 06:33:14 JST
anna
@ska @lanodan (e.g. something like my current 3 gentoo systems with the binhost, about 70~80% of the packages are binary, and 30~20% source compiled, update times range from 3 minutes to 20 depending on what i need to build) -
Embed this notice
anna (navi@social.vlhl.dev)'s status on Friday, 11-Jul-2025 06:33:12 JST
anna
@lanodan @ska
(also don't take all of this too seriously because i'm being *really* autistic about it and trying to have it be "perfect" or whatever) -
Embed this notice
anna (navi@social.vlhl.dev)'s status on Friday, 11-Jul-2025 06:27:53 JST
anna
@ska @lanodan i'm considering a system that has both source and binary packages to install
i do recognize the chance for issue is a lot, a *lot*, smaller with binary package installs, but i still get an itch thinking "this isn't the best we can have right" -
Embed this notice
anna (navi@social.vlhl.dev)'s status on Friday, 11-Jul-2025 06:16:13 JST
anna
@lanodan @ska i'm not even considering portage, portage doesn't even have transactions as it needs build deps installed to / first before building any new packages (though thanks to preserve-libs, any failures won't brick your system)
i'm thinking of a theoretical slashpackage system with per-package atomic updates -- not all packages would be updated at once, and what if that leaves a core tool for booting trying to link against a now unavailable library, or similar issues? because the library itself got updated, but not the tool, or vise-versa -
Embed this notice
anna (navi@social.vlhl.dev)'s status on Friday, 11-Jul-2025 06:07:09 JST
anna
@ska @lanodan also some thoughts:
> and requires a Linux mutant feature
i thought RENAME_EXCHANGE was posix, but it's not -- and afaik updating a symlink isn't atomic, so can the versionless symlink (so, update) be done atomically at all without OS specific features? (or do we like, make a new symlink and rename *the symlink*?)
> allows you to do AB at the *package* level
not having the whole tree be updated atomically is a bit eh, since:
a) wouldn't you need to update a dependency before building a new version of a package? so what if the user tries to launch the old versionless binary before the new version is built and it's symlinks updated?
b) if you solve (a) by somehow building packages with an environment preloaded with their dependencies, so that the versionless symlinks are not touched until time to install, then you start installing new versions one by one, but then lose power midway, now half your versionless links are the old version, and half are the new one, and then dependencies can be mismatched
and i don't think we can solve (b) with per-package environments unless we do wrappers for every single binary, but even then program X might need both libraries Z and Y, and/or Z might also need Y itself, if one is updated and the other isn't, it can just break over wrong SONAME / broken ABI -
Embed this notice
anna (navi@social.vlhl.dev)'s status on Friday, 11-Jul-2025 06:07:08 JST
anna
@ska @lanodan (tl;dr with per-package a/b, if we're doing multiple updates and lose power, some versionless symlinks would be old, some new, and thus inconsistent state) -
Embed this notice
anna (navi@social.vlhl.dev)'s status on Friday, 11-Jul-2025 03:44:41 JST
anna
@puppygirlhornypost2 @ada those people think that they're "poisoning" the LLM by putting that junk out there
but, as i've heard somewhere, "if you piss in an ocean, it's still an ocean" -- those "cleanups" hurt actual people waaaay more than they hurt llm training, if at all -
Embed this notice
anna (navi@social.vlhl.dev)'s status on Friday, 11-Jul-2025 03:22:06 JST
anna
i've honestly had more problem running games on steam with proton + steamrt/pressure-vessel than i ever had with gog/itch.io games and simply `$ wine game.exe`
and i don't mean runtime issues, but simply launch issues
clicking `play` and getting stuck on `launching game`, or just returning to `play` with no error message nor anything, and having to filter over a lot of noise in steams stderr to just find out why -
Embed this notice
anna (navi@social.vlhl.dev)'s status on Friday, 11-Jul-2025 01:20:45 JST
anna
@ska @lanodan something like
/usr is empty on disk
/var/usr/old and /var/usr/latest hold the actual contents
initramfs does `mount --bind $root/var/usr/latest $root/usr` before switch_root (for merged-usr, split-usr can mount it during init, but then /bin, /sbin, and /lib updates won't be atomic)
---
update time, update /var/usr/old
rename RENAME_EXCHANGE /var/usr/old /var/usr/latest # if we lose power here, latest will be picked up next boot, rename is atomic
mount --move /var/usr/latest /usr # atomically apply update to live system
now copy /var/usr/latest to /var/usr/old if that's desired, or keep `old` for "recovery boot" or smth -
Embed this notice
anna (navi@social.vlhl.dev)'s status on Friday, 11-Jul-2025 01:20:44 JST
anna
@lanodan @ska i could also actually do one symlink /usr -> /var/usr/latest tbh... achieve the same goal (without per-package binary symlinks) and without initramfs needing to bind mount anything -
Embed this notice
anna (navi@social.vlhl.dev)'s status on Friday, 11-Jul-2025 00:35:45 JST
anna
@ska @lanodan MS_MOVE is atomic, i can have /var/usr/a and /var/usr/b, be currently using /var/usr/a, install any updates to /var/usr/b, then mount(MS_MOVE) /var/usr/b to /usr
it's linux specific obviously, but fs-agnostic, and it means having at least two full copies of /usr at all times (so, storage inefficient) -
Embed this notice
anna (navi@social.vlhl.dev)'s status on Thursday, 10-Jul-2025 23:42:47 JST
anna
wondering if i can make my (gentoo/portage/pms based) package manager perform live, atomic, and transactional, update installs in a nice way
live: i don't want to need a reboot (neither full nor partial) to get new packages, i feel like that's a big unnecessary limitation of a lot of atomic package managers
atomic: at no moment the rootfs is half-updated
transactional: build all packages then perform any sort of updating, portage is one of the few package manager that don't do this currently afaik, because of it's source-based nature
All GNU social JP content and data are available under the