dynamic linking is nice and good

i love dynamic linking

@q66 I just wish it worked closer to how it does on NT

@toast eh i absolutely don't miss importlibs and similar weirdness

@toast also that in order to use dlls efficiently you have to mark all external linkage dllimport which means you effectively have to pass to the code at build time what type of library you are linking against

@q66 Can't use dynamic linking in NixOS 😭

@Gabriel nixos L

@q66 I mean more in the sense of “you can ship your shared object and swap it out but in a way that’s local to the executable rather than local to the execution environment”
anyway I’m a static linking enjoyer but I would like to just have both be good
unfortunately things are very dynamic skewed so I naturally tend to push more to the static side to have it be closer to a “do what makes sense”
the world actually wants static linking anyway, see: flatpak as etc which just ship every SO together for funnies instead of making the executable more portable

@toast i mean yeah that part is fine but other than that handling of windows dlls is uhh

i don't like static linking in the general case because it erases the real meaning of abi in practice and pushes things more towards being very wrong (like rust with its monomorphization and "compile everything, all at once" is largely enabled by "static link everything")

i want dynamic linking, generics via dynamic dispatch like eg swift (but i'm fine ish with the way c++ does it, if restraint is applied), stable abis, reasonable library management, being able to build all the pieces individually and get all the benefits stemming from that eg patch security issues on the fly without rebuilding world

i don't mind things being statically *linkable* (that should kinda just be implicit because there isn't anything you should be doing that should prevent it, in general) but i'm very sad about where things are going

flatpak is just a result of the whole "give distribution powers back to the developer" which is also its own nasty can of worms because developers generally don't give a shit about a large portion of their potential users

@q66 yea agreed , idk it just feels like statlinking is only ok for increasingly niche usecases (and rust. of course)

@q66 what I really want deep down inside is static linking + dlopen, but this is a can of worms and (like I said in the other thread) I'm a bit tired of the conversation so I'm gonna duck out of it (nothing to do with anyone involved just in case :0)

@toast i'm not sure how i feel about dlopen in general, i kinda feel like restraint should be applied when using it because it means the ldso cannot know ahead of time and symbol resolution at runtime is wonky

separate processes + ipc are ideal (and that also works for static) though not always doable

@Gabriel @q66 what do you mean? aren't nix packages normally dynamically linked? guix packages certainly are

@noisytoot @q66 My bad, you can't use dynamic linking in NixOS without patching the program you want to run

That's why I had (and gave) the impression you couldn't use dlls at all in NixOS

@q66 separate processes and ipc mentioned!!! microkernel OS design enjoyer logging in!!!! 🎉 🎉 🎉
Unix-like systems are my prison and I am never escaping them. —helene

@q66 @toast remember dynamic linking with a.out?

@q66
I kinda miss how AmigaOS did it.
Similar to dlopen().

@kirtai @q66 i don't think dlopen is good as it makes dependency resolution harder to do stastically (you don't know what library it'll load until it asks to) which is pretty bad for security

@SRAZKVT @kirtai @q66 just do a systemd and shove json into a custom elf header /j

(i still can't believe that's what they're pushing for ugh)

@navi @q66 @kirtai right, because a elf header is always correct, and it's impossible to write a dlopen call without updating the header, and there is never a case where dlopen may get a value not expected by a dev, after all, vulnerabilities don't exist

@navi @q66 @kirtai honestly of the three options, dlopen is probably the worst, dynamic linking is, well, dynamic, but what it links with isn't, and if you've got a vuln in your linker you've got other problems, and, well, static linking is the same

@q66 i don't think it's particularly better than static, but it is what systems are built upon, and so should be what is preferred

though i can see a way to make statlinking work on the distribution side, but itd need all packages and software to be done differently to be good (the way i see it is a built but pre link cache (to not need to rebuild everything every time, only relink) and if the package or one of its deps gets updated, it gets relinked and its tests ran, if that fails, the update to that package is abandonned so users keep a working package, and an error is sent to maintainers

again, different model from what we're using right now, and our software doesn't expect that at all, so it's just a neat thought experimentation likely to never see the light of day