Posts by navi@social.vlhl.dev
(DIR) Post #AwAOyvnpkdOFMAmlCy by navi@social.vlhl.dev
2025-07-15T19:10:56.160515Z
1 likes, 0 repeats
@quad oooh -- i need to get over the anxiety of that getting loose and falling -- when i do, i'll get one for sure ~w~
(DIR) Post #AwASTdPcTbSP9un8qm by navi@social.vlhl.dev
2025-07-15T19:42:36.525155Z
1 likes, 0 repeats
$ adb pair ...error: protocol fault (couldn't read status message): Success---okay ig
(DIR) Post #AwAUGwQcfBiGHRKt0q by navi@social.vlhl.dev
2025-07-15T20:08:37.487939Z
1 likes, 0 repeats
been trying for like an hour to just find out how to see the results of my blood tests online, from spain's SIP systemall i get is like 10 redirects followed by a cryptic error
(DIR) Post #AwAXtAz1ITYKHuLei0 by navi@social.vlhl.dev
2025-07-15T20:48:03.015262Z
0 likes, 0 repeats
@ska this is more "it did not report any errors" than "it reported success" for the errno imoachieves the same, but it's different semantics, and less intuitive imo
(DIR) Post #AwAZgrM8e0AHqgPt2G by navi@social.vlhl.dev
2025-07-15T20:57:29.565899Z
0 likes, 0 repeats
question: since thread_local exists, is there any technical issue to giving the user of a library extra failure information out of band in a errno-like way?most of my personal code returns an status enum from the function anywayso i'm just curious if there's any actual issues with the alternative of a thread_local status flag, maybe around ffi? or something else?
(DIR) Post #AwCK8WGewS2a87bqvQ by navi@social.vlhl.dev
2025-07-16T12:36:48.064033Z
1 likes, 0 repeats
i need a fucking dev blog ngl
(DIR) Post #AwCKBYc6fyu2H55dSK by navi@social.vlhl.dev
2025-07-16T12:36:28.160178Z
0 likes, 0 repeats
i think i misunderstood soname for a while nowthey’re supposed to encode abi, not api, and not supposed to match your package version at all, that’s apiso there’s 3 cases:1: whenever your abi changes, you bump the soname. abi-only changes of a library are usually exclusive to when the members are added to a structure, or type sizes are changed (at least i can’t think of any other “usual” change that would change abi without changing api) – abi-only changes means code using your library only needs to be recompiled, nothing else.2: when your api changes, so function names/parameter changes, struct member changes, you bump both the package major version, and the soname, since an api changes means you need to edit code and recompile3: when you add things to your api and abi, but don’t change anything that already exists, the library is still backwards compatible, soname doesn’t change, you bump only the minor semver and minor sonameso for a given libnya.so, from package dev-utils/nya-1.90.2 there could be:libnya.so.1, soname, this is what elf binaries write as DT_NEEDED, this indicates libnya‘s abi constraints, aka your “abi major version” libnya.so, this is what the compiler looks for when you do -lnya, meant to be “the latest ABI” libnya.so.1.34, this is the full qualified SONAME, so abi-major.abi-minorand they would be symlinked as such: libnya.so -> libnya.so.1 -> libnya.so.1.34say you add a new function to libnya, not touching any current abi, then all you do is replace libnya.so.1.34 with libnya.so.1.35if you break abi, even if you don’t touch the api, you would then install libnya.so.2.0, and update the symlink libnya.so -> libnya.so.2 -> libnya.so.2.0 – and yes, this means that the package nya-1.91 would install libnya.so.2note that currently installed applications are still using libnya.so.1, even if you install libnya.so.2.0 and move the libnya.so symlink! which means that if you update the soname to 2.0, you can keep libnya.so.1 installed (without a new generic symlink) concurrently, and old binaries will still work (looking at you arch/pacman, who removes old abi libraries while there’s still programs using it installed, “partial upgrades are not supported” is not an excuse to suck like this) – only remove that old soname when there’s no more packages using itthat covers cases 1 and 3 quite well, though it’s not perfect for case 3, more on that latercase 2 is the issue on this system. your api changed, meaning your abi changed too. you could think of this as the same as case 1 and just bump the soname, aka abi-major, when releasing nya-2.0, but that’s not ideal, because what if the user has two programs, one that uses nya-1 and another that uses nya-2 – if you only bump soname, you won’t be able to build both (without shenanigans) since -lnya would always resolve to libnya.so.3 aka nya-2‘s shared objectthere is, however, a solution to this, it’s just not pretty, and imo, a huge hack on what so far seemed like a clean system, insert your API constrains in the shared object name, then reset soname, so nya-2 would ship libnya2.so -> libnya2.so.1 -> libnya2.so.1.0this separates the api changes from the abi, and allows libnya2.so and libnya.so to exist at the same timeso in the end the library naming scheme gets to lib[name][api-major].so.[abi-major].[abi-minor]i don’t like putting the api major in the library name at all, it’s ugly, it incentives people to not do major bumps (who wants to ship a file named libnya13.so.1? where the users have to -lnya13 to use it)i wish the api was actually part of the soname mechanism, in a better way – however, this is how it is, i can’t think of anything better, at least not currently, with our current toolchains. a solution, one often used by distros, is to install to different prefixes, and do -L/usr/lib/libnya-1 or -L/usr/lib/libnya-2, and each would have their own libnya.so -> libnya.so.{2,3} symlink respectively – works, it’s less ugly than putting the api on the name, but still feels hacky to me, split out /usr/lib into multiple small subdirs just for versioned parallel installs, and require lengthy compiler invocations with full search paths for every single library, overall ugly imo though this one works way nicer when the distro already installs packages in isolation, something like nix or slashpackage, since you can have the default symlink in /usr/lib be the latest version, and only provide -L for older version. on more traditional distros doing this would mean putting every single library in a split subdir even if it’ll never have parallel installs ever, which i would strongly dislike to doanother one solution, which would be my prefered since it’s more semantic and systematic, would be to able to specify the soname in the cc invocation, -lnya.2 would use libnya.so.2 directly, even tho libnya.so -> libnya.so.3 exists. but currently this doesn’t quite work. gcc/clang support -l:filepath, (though not posix cc/c17), but pkg-config and other tooling don’t really work with that, and since it’s a fully qualified pathname, it would basically break --static flags in some build toolslastly, for case 3, soname makes shared objects abi-backwards-compatible, and gives mechanism for detecting when rebuilds are necessary (soname bump, .so.2 to .so.3), but they have no way to specify a minimum minor version, so a library that uses a symbol only present in libnya.so.1.39, can’t in any way specify that libnya.so.1.38 will not work, but libnya.so.1.40 willor you could be like glibc and freeze your soname, and whenever you need to make a change make a new symbol and keep carrying all your old source code versions for all eternity :)did i get anything wrong, or miss anything?
(DIR) Post #AwCKBa5vAcLUrq2xZA by navi@social.vlhl.dev
2025-07-16T12:51:46.656495Z
1 likes, 0 repeats
one key takeway i had from this soname / abi != package-version / api is that adding fields to structures shouldn’t be a thing to worry about that much, removing them yes, adding, reordering, etc, nolibraries shouldn’t keep their data “obscured” behind a malloc-d pointer just for the sake of binary compatibility. there is other reasons for opaque pointers, but more often than not, a library will be better by letting users choose where to allocate data, be it on the stack or on the heap or statically or so onand if you worry about people accessing fields they shouldn’t, c23 provides [[deprecated]], meaning you can do:#if !defined(MYLIB_INTERNAL) && __STDC_VERSION__ >= 202311L# define mylib_private [[deprecated("private struct member, do not use.")]]#else# define mylib_private#endifand mark struct members as suchdistros should have mechanism to easily trigger rebuilds on soname changes, as well as mechanisms to keep the old soname around as long as there’s packages linked to itthe fact that some distros don’t, is not a limitation of the system, but an implementation failure
(DIR) Post #AwCOLWVNlmsYRox6Uy by navi@social.vlhl.dev
2025-07-16T17:53:06.081847Z
0 likes, 0 repeats
@lanodan @ska at least with pkg-config it's easier to abstract moving the headers or adding libdirs to the search path (just changing the .pc file suffices)it gets a lot annoying when someone's handcrafted makefile does -lfoo directly, with no checks no anything
(DIR) Post #AwCem1OL9j5X2IJd1U by navi@social.vlhl.dev
2025-07-16T21:14:12.508744Z
1 likes, 0 repeats
would be funny to ship a game, for posix systems, that uses d3d12 and thus depends on vkd3d unixlibunfortunately i'm allergic to directx apis and should not come in contact with them outside working hours
(DIR) Post #AwCkyPAXB4bNyp97DM by navi@social.vlhl.dev
2025-07-16T21:58:52.856264Z
1 likes, 0 repeats
i honestly can't with people complaining that a init system, which has the job of bringing your system up, and execute the commands necessary to do that...is turing complete therefore bad?????????
(DIR) Post #AwCnhwSMShJY9vKGnI by navi@social.vlhl.dev
2025-07-16T22:57:19.801910Z
1 likes, 0 repeats
@dalias the context is pretty much someone shooting down openrc and proclaiming systemd "the only good one", that since openrc uses shell scripts for it's system service definitions, unit files are better because .ini is not turing completei don't feel like it's applicable to service definitions, the person said that unit files being non turing complete stops people adding "all sorts of crazy logic", but they don't really, people still put wrapper shell scripts in ExecStart, or concoct pseudo script with 20 ExecStartPre lineswhat actually helps reduce the crazy (and usually faulty) logic is the init system providing interfaces for things that most services will need -- and that is something we're working on a lot in openrc
(DIR) Post #AwCwIxD5QE2qqPLCYi by navi@social.vlhl.dev
2025-07-17T00:32:32.068291Z
1 likes, 0 repeats
@ska @dalias @david_chisnall @danirabbit > Is the hostility still prevalent today?i got into linux and foss recently (well, in the past ~4 years) (tho also i'm a trans woman (so unsure if my input is helpful at all))while most of the spaces i'm in are still mostly full of men, i don't really feel the hostility that teen me would feel in a lot of places spaces (granted, back then non-foss ones, but still tech and gaming spaces)the few spaces i've been in that are not mostly men, are my fedi bubble which is mostly trans women, and during fossdem earlier this year, where gf and i got randomly invited to a women & queer only breakfast -- that was one of the very few times i've actually interacted with cis women in a foss spaces/contextthe spaces i found online are most men, and sometimes there's a few bubbles with gender queer folks, mostly trans women, and i barely ever see cis women aroundand honestly i got kinda lucky still, since when i first wanted to leave arch linux and try a non-systemd distro (so around 2021), i picked gentoo simply because i watched a video about it, and it seemed coolgentoo's community was kind of my first step to participating in foss more than just as a user, i met one of the devs, and made friends -- that community was welcoming, and from there i interacted with foss more, with wayland folks, started writing my first openrc patches, and so onbut just as well i could've tried artix which was suggested to me, and that community is, by what i've been told and the bits i've interacted with, not good for one's mental health, it has the hostility mentioned, with extra "alt-right" polities of modern "no politics here only code" foss -- similar things could happen if i had taken any interest on hyprland over sway back then too, if i had fell into one of those communities first, there's a high likelihood i would've quit this whole foss communities thing
(DIR) Post #AwE4DrFN9ujth3S1uy by navi@social.vlhl.dev
2025-07-17T13:22:27.772275Z
2 likes, 0 repeats
36°Ci left brazil, but brazil didn't leave me
(DIR) Post #AwENdKu1w1Bm2PKZwu by navi@social.vlhl.dev
2025-07-17T16:59:18.314281Z
1 likes, 0 repeats
dandadan's opening is fire
(DIR) Post #AwEO5xv8SdkN9qV1bU by navi@social.vlhl.dev
2025-07-17T17:16:34.528771Z
1 likes, 0 repeats
it's so hot that i can't use my laptop on my laplike at all
(DIR) Post #AwEPRMoBDvhWNi0zB2 by navi@social.vlhl.dev
2025-07-17T17:25:45.628550Z
1 likes, 0 repeats
@lanodan okay how did i not think of thatgot a piece of plywood we had laying around
(DIR) Post #AwG5GpFvVTCgeobpRo by navi@social.vlhl.dev
2025-07-18T12:31:03.946507Z
0 likes, 0 repeats
is there an affordable VR or AR head display thingy that works on linux?i want to try things
(DIR) Post #AwG5kRae3mhBwkQIds by navi@social.vlhl.dev
2025-07-18T13:01:33.149473Z
0 likes, 0 repeats
@SuperDicq while i do want to play beat saber and hl alyx, currently i'm kind of more interested in seeing how XR wayland compositors work and behave, so controllers are not a big requirement at the time, i'll look into monado then
(DIR) Post #AwGZxg2edZSL9okaZc by navi@social.vlhl.dev
2025-07-18T14:54:37.857616Z
1 likes, 0 repeats
@dalias while i don't use an ide, i do use neovim with a lsp for cmostly because i have a tendency to typo things and the "edit, save, compile, look at errors" loop is overwhelming to me, seeing only errors on the line (or around it) i'm working on helps a lot. also sometimes for auto-complete when function names are like namespaced plus long namesbut to me they're just aids, languages or frameworks that depend on such things to exist feels like they're going backwards: "oh those helpers exist therefore we can make the underlying thing complex as no one will interact with it" is the opposite way technologies should go imo